about the libc++ conversion

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

about the libc++ conversion

rjvbertin
Hi,

This is mostly out of curiosity and for personal education.

I've been tinkering a bit with the libcxx port, upgrading it to 4.0.0 and getting it to build on Linux to have a reproducable way of installing libc++ there.

I went with the standard build that uses libstdc++ instead of libc++abi but from what I saw it can also be built to use a (static) copy of libsupc++ (the true equivalent of libc++abi from what I understand).

I then built a Qt5 application using clang -stdlib=libc++ knowing that Qt5 and everything else is built with gcc6 and against libstc++, expecting to see exactly what can go wrong when you mix those 2 runtime libraries.

The answer is zip, nada, there's nothing indicating I'm using 2 different C++ runtimes. Maybe the application actually doesn't use libc++ at all, but it does beg the question if this couldn't have been an approach to simplify the libc++ conversion on older OS X versions.

Note that I'm doing something comparable (but even wilder) with my libc++ conversion of GCC; the system libc++ on OS X 10.9 lacks at least 1 delete function, and thus I pull in libsupc++ when linking with my libc++-enabled g++-mp-7 . This has worked fine until now with everything I've thrown at it.

R.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about the libc++ conversion

Chris Jones
Hi,

The fact that in some cases mixing the two C++ runtimes does not lead to
obvious issues is *not* a general proof that there is not a problem in
doing this. The issues generally occur when the application passing
information between the two runtimes, if in those two runtimes the same
type of object (std::string is a prime example) does not have the same
implementation.

So all you have proved is, in your examples, you do not trip over this.
You have not proved in gerenal it is a safe thing to do.

Chris

On 02/06/17 12:10, René J.V. Bertin wrote:

> Hi,
>
> This is mostly out of curiosity and for personal education.
>
> I've been tinkering a bit with the libcxx port, upgrading it to 4.0.0 and getting it to build on Linux to have a reproducable way of installing libc++ there.
>
> I went with the standard build that uses libstdc++ instead of libc++abi but from what I saw it can also be built to use a (static) copy of libsupc++ (the true equivalent of libc++abi from what I understand).
>
> I then built a Qt5 application using clang -stdlib=libc++ knowing that Qt5 and everything else is built with gcc6 and against libstc++, expecting to see exactly what can go wrong when you mix those 2 runtime libraries.
>
> The answer is zip, nada, there's nothing indicating I'm using 2 different C++ runtimes. Maybe the application actually doesn't use libc++ at all, but it does beg the question if this couldn't have been an approach to simplify the libc++ conversion on older OS X versions.
>
> Note that I'm doing something comparable (but even wilder) with my libc++ conversion of GCC; the system libc++ on OS X 10.9 lacks at least 1 delete function, and thus I pull in libsupc++ when linking with my libc++-enabled g++-mp-7 . This has worked fine until now with everything I've thrown at it.
>
> R.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about the libc++ conversion

Ken Cunningham Webuse
In reply to this post by rjvbertin
> simplify the libc++ conversion on older OS X versions

I'm working on something related.

It turns out that Clang-3.8 / llvm 3.8  builds without too much trouble on 10.5 PPC, using gcc6 to build it (see my trac tickets if you would like to see how to do that).

It can then build quite complex applications (aria2, pan, many more) that appear to run correctly, and link them against either libstdc++ (system) or libc++  (if you need cxx11 features). It can't build all applications, though, and there are some remaining potholes (e.g. exceptions, at the moment).

To have complete harmony all the c++ ports need to link against the same std library, but as you have noted, quite often in day-to-day use there is no problem if they don't.

If I could get clang-3.9 to build, I could use Marcus' adjustment to allow it's executables to link against gcc's libstdc++ and get harmony that way, perhaps.

Alternatively I might turn to your gcc modifications and get gcc to link it's binaries against libc++, and fix it like that.

K


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about the libc++ conversion

rjvbertin
In reply to this post by rjvbertin
Chris Jones wrote:


> So all you have proved is, in your examples, you do not trip over this.
> You have not proved in gerenal it is a safe thing to do.

Not claiming to either, and I have tried Qt code above all. While usually highly
complex I don't think it uses many STL or std classes.

However, if I read what's said about this on Linux forums I get the impression
that the linker should or might raise errors because of the use of different
namespaces.

BTW, is when using shared libraries the order in which they're listed on the
linker command line determining which library provides which symbols as it is
with static libraries?

R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about the libc++ conversion

Ken Cunningham Webuse
In reply to this post by Ken Cunningham Webuse
> However, if I read what's said about this on Linux forums I get the impression
> that the linker should or might raise errors because of the use of different
> namespaces.

That's right. I've seen errors that look like this, with this std::__1 business:

Undefined symbols for architecture x86_64:
 "glbinding::setAfterCallback(std::__1::function<void (glbinding::FunctionCall const&)>)", referenced from:
     Gl::initialize(Gl::Trace const&, SDL_Window*, int*) in libgraphic_gl_utils.a(initialize.cc.o)
 "glbinding::setCallbackMaskExcept(glbinding::CallbackMask, std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)", referenced from:
     Gl::initialize(Gl::Trace const&, SDL_Window*, int*) in libgraphic_gl_utils.a(initialize.cc.o)
 "glbinding::AbstractValue::asString() const", referenced from:
     std::__1::__function::__func<Gl::initialize(Gl::Trace const&, SDL_Window*, int*)::$_0, std::__1::allocator<Gl::initialize(Gl::Trace const&, SDL_Window*, int*)::$_0>, void (glbinding::FunctionCall const&)>::operator()(glbinding::FunctionCall const&) in libgraphic_gl_utils.a(initialize.cc.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


See <https://stackoverflow.com/questions/29293394/where-does-the-1-symbol-come-from-when-using-llvms-libc> and many other similar references on the web.

Ken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about the libc++ conversion

rjvbertin
In reply to this post by Chris Jones
Chris Jones wrote:


> type of object (std::string is a prime example) does not have the same
> implementation.

Do we have known examples that trigger the issue reliably?

As to the linker raising errors thanks to the use of different namespaces:

CMakeFiles/KDevPlatformShell.dir/plugincontroller.cpp.o: In function
`PluginController':
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-
kdevplatform-devel/work/kf5-kdevplatform-5/shell/plugincontroller.cpp:272:
undefined reference to `KPluginLoader::findPlugins(QString const&,
std::__1::function<bool (KPluginMetaData const&)>)'
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-
kdevplatform-devel/work/kf5-kdevplatform-5/shell/plugincontroller.cpp:288:
undefined reference to `KPluginLoader::findPlugins(QString const&,
std::__1::function<bool (KPluginMetaData const&)>)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

(building KDevPlatformShell with `clang -stdlib=libc++` on Linux and using
KPluginLoader from a library built with GCC 6.2/libstdc++.)

Thanks,
René

Loading...