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

[Fons Rademakers]

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
>

-- 
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/584cd6c1/attachment.bin>