x3 linker error with separate TU

[Olaf Peter]

Hello,

this refers to a question at stackoverflow, where since 14 days no
answer is known. From my side I've checked the related answers on
stackoverflow but there seems to be no solution:
https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-tu


Maybe here is a better place to get an answer since the rule count rises
and the compile time increases ... The problems stays with boost 1.64.0
and gcc-7.10/clang-3.91 too.


Thanks,

Olaf


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[cppljevans]

On 05/22/2017 11:10 AM, Olaf Peter wrote:

> Hello,
>
> this refers to a question at stackoverflow, where since 14 days no
> answer is known. From my side I've checked the related answers on
> stackoverflow but there seems to be no solution:
> https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-tu
>
>
> Maybe here is a better place to get an answer since the rule count rises
> and the compile time increases ... The problems stays with boost 1.64.0
> and gcc-7.10/clang-3.91 too.
>
>

It seems to work with:

https://github.com/cppljevans/spirit/tree/get_rhs

at least based on the attached compilation.out and a
slight change to the source, main.cpp, where:

#define BOOST_ERROR_CODE_HEADER_ONLY

was added at the top.

HTH.

-regards,
Larry




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[Olaf Peter]

Hello Larry,

> On 05/22/2017 11:10 AM, Olaf Peter wrote:
>> Hello,
>>
>> this refers to a question at stackoverflow, where since 14 days no
>> answer is known. From my side I've checked the related answers on
>> stackoverflow but there seems to be no solution:
>> https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-tu 
>>
>>
>>
>> Maybe here is a better place to get an answer since the rule count rises
>> and the compile time increases ... The problems stays with boost 1.64.0
>> and gcc-7.10/clang-3.91 too.
>>
>>
> It seems to work with:
>
> https://github.com/cppljevans/spirit/tree/get_rhs
>
> at least based on the attached compilation.out and a
> slight change to the source, main.cpp, where:
>
> #define BOOST_ERROR_CODE_HEADER_ONLY
>
> was added at the top.

Thank you for investigating. At this time I haven't access to my project

but I will confirm if it works (or even not).

What is the reason for these linker error? Are there chances that the
fix will be included into boost 1.65?

BTW, during investigating I played with x3's calc9 and wrote a CMake
file, where a static link library was created. The resulting exe crashed:

 1.
    gdb ./calc9
 2.
    GNU gdb (GDB) Fedora 7.12.1-48.fc25
 3.
    [...]
 4.

 5.
    Using host libthread_db library "/lib64/libthread_db.so.1".
 6.
 7.
    Program received signal SIGSEGV, Segmentation fault.
 8.
    0x000000000042bcd8 in boost::shared_ptr<boost::spirit::x3::tst<char,
    client::ast::optoken> >::operator-> (this=0x10) at
    /usr/include/boost/smart_ptr/shared_ptr.hpp:693
 9.
    693       BOOST_ASSERT( px != 0 );
10.
    Missing separate debuginfos, use: dnf debuginfo-install
    boost-system-1.60.0-10.fc25.x86_64
11.
    (gdb) bt
12.
    #0  0x000000000042bcd8 in
    boost::shared_ptr<boost::spirit::x3::tst<char, client::ast::optoken>
     >::operator-> (this=0x10) at
    /usr/include/boost/smart_ptr/shared_ptr.hpp:693
13.
    #1  0x000000000042aed8 in
    boost::spirit::x3::symbols_parser<boost::spirit::char_encoding::standard,
    client::ast::optoken, boost::spirit::x3::tst<char,
    client::ast::optoken> >::adder::operator()<char [3]> (this=0x660a80
    <client::parser::logical_op>, s=...,
14.
    val=@0x7fffffffdb5c: client::ast::op_and) at
    /usr/include/boost/spirit/home/x3/string/symbols.hpp:262
15.
    #2  0x0000000000429342 in client::parser::add_keywords () at
    /home/olaf/work/CXX/ReferenceDesigns/x3_calc9/expression_def.hpp:46
16.
    #3  0x00000000004295c5 in client::expression () at
    /home/olaf/work/CXX/ReferenceDesigns/x3_calc9/expression_def.hpp:176
17.
    #4  0x0000000000413c23 in __static_initialization_and_destruction_0
    (__initialize_p=1, __priority=65535) at
    /home/olaf/work/CXX/ReferenceDesigns/x3_calc9/statement_def.hpp:42
18.
    #5  0x0000000000413d7b in _GLOBAL__sub_I__ZN6client9statementEv ()
    at /home/olaf/work/CXX/ReferenceDesigns/x3_calc9/statement.cpp:13
19.
    #6  0x000000000043ae9d in __libc_csu_init ()
20.
    #7  0x00007ffff6f8d390 in __libc_start_main () from /lib64/libc.so.6
21.
    #8  0x0000000000403bba in _start ()


Did I use X3 in way not intended to be used? Is this related to the
linker error on topic here? Note, no BOOST_SPIRIT_X3_DEBUG is defined
where rise other problems too (following this ML and SO).

Using a single pass (g++ -I . expression.cpp statement.cpp compiler.cpp
vm.cpp main.cpp -o ../x3_calc9_BUILD/calc9 -lboost_system) the exe was
functional.

Thanks,
Olaf


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[cppljevans]

On 05/26/2017 12:47 PM, Olaf Peter wrote:

> Hello Larry,
>> On 05/22/2017 11:10 AM, Olaf Peter wrote:
>>> Hello,
>>>
>>> this refers to a question at stackoverflow, where since 14 days no
>>> answer is known. From my side I've checked the related answers on
>>> stackoverflow but there seems to be no solution:
>>> https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-tu 
>>>
>>>
>>>
>>> Maybe here is a better place to get an answer since the rule count rises
>>> and the compile time increases ... The problems stays with boost 1.64.0
>>> and gcc-7.10/clang-3.91 too.
>>>
>>>
>> It seems to work with:
>>
>> https://github.com/cppljevans/spirit/tree/get_rhs
>>
>> at least based on the attached compilation.out and a
>> slight change to the source, main.cpp, where:
>>
>> #define BOOST_ERROR_CODE_HEADER_ONLY
>>
>> was added at the top.
> Thank you for investigating.

You're welcome

? At this time I haven't access to my project
> but I will confirm if it works (or even not).
Thanks.
>
> What is the reason for these linker error?

Possibly the reason is as explained by Seth here:

 
http://boost.2283326.n4.nabble.com/Linking-error-when-changing-gt-to-gt-gt-tt4689820.html#a4689860

and I *guess* the attribute transform Seth talked about was that
encapsulated in rule_attr_transform here:

https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L311

and where rule_attr_transform is done is governed by the macro:

   BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM

IIRC, Seth mentioned something about a solution by keeping the attribute
"synchronized" with what's required the parse function and,
somehow, when BOOST_SPIRIT_DEFINE is use, it's "synchronized",
but when BOOST_SPIRIT_DECLARE and BOOST_SPIRIT_INSTANTIATE are used,
it, for some reason, get's "out-of-sync".
I'm still trying to understand how it works :(


> Are there chances that the
> fix will be included into boost 1.65?

I could do a pull request now.  Does that sound OK Joel?

>
> BTW, during investigating I played with x3's calc9 and wrote a CMake
> file, where a static link library was created. The resulting exe crashed:
[snip]

> 11.
>     (gdb) bt
> 12.
>     #0  0x000000000042bcd8 in
>     boost::shared_ptr<boost::spirit::x3::tst<char, client::ast::optoken>
>      >::operator-> (this=0x10) at
                            ^^^^ highly suspicious!  I doubt 0x10
                                 is a valid address.
>     /usr/include/boost/smart_ptr/shared_ptr.hpp:693
[snip]

>
> Did I use X3 in way not intended to be used? Is this related to the
> linker error on topic here?
Sorry, I've no idea.
> Note, no BOOST_SPIRIT_X3_DEBUG is defined
> where rise other problems too (following this ML and SO).
>
> Using a single pass (g++ -I . expression.cpp statement.cpp compiler.cpp
> vm.cpp main.cpp -o ../x3_calc9_BUILD/calc9 -lboost_system) the exe was
> functional.

Strange!

>
> Thanks,
> Olaf
>
Sure.  Sorry I couldn't be more help.  Will study problem further.

-regards,
Larry



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[cppljevans]

On 05/26/2017 03:44 PM, Larry Evans wrote:
[snip]

> and I *guess* the attribute transform Seth talked about was that
> encapsulated in rule_attr_transform here:
>
> https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L311 
>
>
> and where rule_attr_transform is done is governed by the macro:
>
>    BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
>

OOPS.  That should be:

   BOOST_SPIRIT_ATTR_XFORM_IN_RULE

I've only a foggy memory of what BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM is
for.  Maybe the get_rhs fork is not ready for pull request now :(
[snip]


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[cppljevans]

On 05/26/2017 03:44 PM, Larry Evans wrote:
> On 05/26/2017 12:47 PM, Olaf Peter wrote:
[snip]

>> BTW, during investigating I played with x3's calc9 and wrote a CMake
>> file, where a static link library was created. The resulting exe crashed:
> [snip]
>
>> 11.
>>     (gdb) bt
>> 12.
>>     #0  0x000000000042bcd8 in
>>     boost::shared_ptr<boost::spirit::x3::tst<char, client::ast::optoken>
>>      >::operator-> (this=0x10) at
>                             ^^^^ highly suspicious!  I doubt 0x10
>                                  is a valid address.
>>     /usr/include/boost/smart_ptr/shared_ptr.hpp:693
> [snip]
>
>>
>> Did I use X3 in way not intended to be used? Is this related to the
>> linker error on topic here?
> Sorry, I've no idea.

[snip]
However, I wouldn't think so.  Instead, it seems more like a memory
problem.  You might try:

http://valgrind.org/docs/manual/quick-start.html#quick-start.mcrun

Unfortunately, I've little experience with it; hence, I probably
won't be much help in case you have problems with using valgrind :(

-regards,
Larry


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[Olaf Peter]

Hello Larry,

> On 05/26/2017 03:44 PM, Larry Evans wrote:
> [snip]
>
>> and I *guess* the attribute transform Seth talked about was that
>> encapsulated in rule_attr_transform here:
>>
>> https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L311 
>>
>>
>> and where rule_attr_transform is done is governed by the macro:
>>
>>    BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
>>
> OOPS.  That should be:
>
>   BOOST_SPIRIT_ATTR_XFORM_IN_RULE
>
> I've only a foggy memory of what BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
> is for.  Maybe the get_rhs fork is not ready for pull request now :(

thank you for your effort! I did clone your
https://github.com/cppljevans/spirit/tree/get_rhs into the sources and
changed the CMake file accordingly , but run into compile errors now.
The defines are taken from your responses, also your successfully
finished compile log file above.

But following your links there seems to be  no easy solution yet.
Fortunately it's a spare time project ...

Or, do I miss something?

Thanks,
Olaf




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[cppljevans]

On 05/27/2017 01:09 PM, Olaf Peter wrote:

> Hello Larry,
>> On 05/26/2017 03:44 PM, Larry Evans wrote:
>> [snip]
>>
>>> and I *guess* the attribute transform Seth talked about was that
>>> encapsulated in rule_attr_transform here:
>>>
>>> https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L311 
>>>
>>>
>>> and where rule_attr_transform is done is governed by the macro:
>>>
>>>    BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
>>>
>> OOPS.  That should be:
>>
>>   BOOST_SPIRIT_ATTR_XFORM_IN_RULE
>>
>> I've only a foggy memory of what BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
>> is for.  Maybe the get_rhs fork is not ready for pull request now :(
>
> thank you for your effort! I did clone your
> https://github.com/cppljevans/spirit/tree/get_rhs into the sources and
> changed the CMake file accordingly , but run into compile errors now.
> The defines are taken from your responses, also your successfully
> finished compile log file above.
>
> But following your links there seems to be  no easy solution yet.
> Fortunately it's a spare time project ...
>
> Or, do I miss something?

I think you're using develop branch instead of get_rhs branch.
On develop, at:

 
https://github.com/cppljevans/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L241

the rat_v.post call is passed 3 args, but on get_rhs, at:

 
https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/rule.hpp#L235

the rat_v.post call is passed the correct 2 args.

So, checkout get_rhs and see if that doesn't solve the problem.


>
> Thanks,
> Olaf

You're welcome, Olaf.  Good luck!

-regards,
Larry



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

[Olaf Peter]

Hello Larry,

> On 05/27/2017 01:09 PM, Olaf Peter wrote:
>> Hello Larry,
>>> On 05/26/2017 03:44 PM, Larry Evans wrote:
>>> [snip]
>>>
>>>> and I *guess* the attribute transform Seth talked about was that
>>>> encapsulated in rule_attr_transform here:
>>>>
>>>> https://github.com/cppljevans/spirit/blob/get_rhs/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L311 
>>>>
>>>>
>>>> and where rule_attr_transform is done is governed by the macro:
>>>>
>>>>    BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM
>>>>
>>> OOPS.  That should be:
>>>
>>>   BOOST_SPIRIT_ATTR_XFORM_IN_RULE
>>>
>>> I've only a foggy memory of what
>>> BOOST_SPIRIT_DISABLE_RULE_ATTR_XFORM is for.  Maybe the get_rhs fork
>>> is not ready for pull request now :(
>>
>> thank you for your effort! I did clone your
>> https://github.com/cppljevans/spirit/tree/get_rhs into the sources
>> and changed the CMake file accordingly , but run into compile errors
>> now. The defines are taken from your responses, also your
>> successfully finished compile log file above.
>>
>> But following your links there seems to be  no easy solution yet.
>> Fortunately it's a spare time project ...
>>
>> Or, do I miss something?
>
> I think you're using develop branch instead of get_rhs branch.
> On develop, at:

You are correct, github shows the get_rhs branch, but copy URL doesn't
copy this. I had explicit specify the branch (for non affine git-users:
$git clone --branch get_rhs https://github.com/cppljevans/spirit.git 
destination). Now it compiles.

Thanks again,
Olaf

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general