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

[Yaron Keren]

Hi Fons,

On Windows, I have seen this error as the result of having loaded a shared
library compiled by gcc against libstdc++ looking for its imports.

Yaron



2013/11/20 Fons Rademakers <Fons.Rademakers at cern.ch>

> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131120/7f4975f8/attachment.html>