[cfe-dev] JIT fails linking to libc++ symbols...

[Fons Rademakers]

Alas, removing this flag does not make any difference. JIT still fails to 
link. Any other ideas on what might be going on?

Cheers, Fons.


On 19/11/2013 22:53, Fons Rademakers wrote:
> Ah, now I remember we build LLVM with the flag:
>
> --disable-visibility-inlines-hidden
>
> passed to ./configure, so there must be some interference. I'll try without
> this flag.
>
> Cheers, Fons.
>
>
> On 19/11/2013 21:28, Marshall Clow wrote:
>>
>> On Nov 18, 2013, at 2:13 PM, Fons Rademakers <Fons.Rademakers at cern.ch>
>> wrote:
>>
>>> Hi,
>>>
>>>   since moving to OSX 10.9 with libc++ our code which uses the JIT to
>>> compile C++ code on the fly fails to link with certain libc++ symbols
>>> that are reported by nm to be of type t (small t, i.e. defined but not
>>> exported, if I understand correctly). So, why does the JITted code want
>>> to link with these symbols? How to avoid that or how to make these
>>> symbols available in one way or another. Prior with libstdc++ (on OSX
>>> and Linux) no problems.
>>>
>>> This are some of the symbols that fail linking:
>>>
>>> ExecutionContext: use of undefined symbol
>>> '_ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE13get_allocatorEv'!
>>>
>>> ExecutionContext: use of undefined symbol
>>> '_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKS4_'!
>>> ExecutionContext: use of undefined symbol
>>> '_ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE4sizeEv'!
>>> ExecutionContext: use of undefined symbol
>>> '_ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE4dataEv'!
>>>
>>> That is:
>>>
>>> std::__1::basic_string<char, std::__1::char_traits<char>,
>>> std::__1::allocator<char> >::basic_string(std::__1::allocator<char> const&)
>>> std::__1::basic_string<char, std::__1::char_traits<char>,
>>> std::__1::allocator<char> >::size() const
>>> std::__1::basic_string<char, std::__1::char_traits<char>,
>>> std::__1::allocator<char> >::data() const
>>> std::__1::basic_string<char, std::__1::char_traits<char>,
>>> std::__1::allocator<char> >::get_allocator() const
>>
>> All of those routines are decorated in the header <string> with
>> "_LIBCPP_INLINE_VISIBILITY", which expands to
>> either:    __attribute__ ((__always_inline__))
>> or:        __forceinline
>> (depending on your compiler)
>>
>> Since they're supposed to be always inlined, it's not surprising that
>> they are not in the dylib.
>> A followup question would be: How/why are you generating calls to them,
>> as opposed to just inlining them?
>>
>> -- Marshall
>>
>> Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>
>>
>> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
>> promptly moderated down to (-1, Flamebait).
>>          -- Yu Suzuki
>>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4161 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131119/c9f12a94/attachment.bin>