Libcxx postinst says that: elog "This package (${PN}) is mainly intended as a replacement for the C++" elog "standard library when using clang." elog "To use it, instead of libstdc++, use:" elog " clang++ -stdlib=libc++" elog "to compile your C++ programs." But homepage of libcxx says that: Build on Linux using CMake and libcxxrt. ... Unfortunately you can't simply run clang with "-stdlib=libc++" at this point, as clang is set up to link for libc++ linked to libsupc++. To get around this you'll have to set up your linker yourself (or !!!patch clang!!!). Reproducible: Always Steps to Reproduce: 1.USE=libcxxrt emerge libcxx Actual Results: clang -stdlib=libc++ can show error about undefined reference we should add manualy -lcxxrt Expected Results: if patch clang clang -stdlib=libc++ will work out of box Patch is simplest but for determine USE flags of libcxx we should add libcxxrt to USE flags of clang and add sys-libs/libcxx[libcxxrt=] to PDEPEND. And I don't understand why clang haven't dependency to libcxx already. clang -stdlib=libc++ That standard feature of clang and should supported out of box. But if we haven't libcxx in world it's not work.
Created attachment 353848 [details, diff] clang-libcxxrt.patch
Does 'clang -stdlib=libc++' work out-of-the-box when libcxx is built without USE=-libcxxrt?
(In reply to Michał Górny from comment #2) > Does 'clang -stdlib=libc++' work out-of-the-box when libcxx is built without > USE=-libcxxrt? yes, but without USE=-libcxxrt libcxx have incomplete ebuild for static-libs suport ), and 'clang -stdlib=libc++ -static' maybe doesn't work out-of-the-box :) but this is separate and i haven't tested static-libs
Clang link gcc in executable by default and for shared linking libsupc++ in libgcc already, but for static linking i'm not sure libsupc++.so not exist. but libsupc++.a exist maybe we can write ldscript for libcxx with USE="-libcxxrt static-libs" in simple way, but i'm not sure
I don't like the patch, to be honest. Dependencies for libcxx should be handled in libcxx rather than embedded in clang. Though I know that static linking in Linux sucks pretty hard...
(In reply to Michał Górny from comment #5) > I don't like the patch, to be honest. Dependencies for libcxx should be > handled in libcxx rather than embedded in clang. Though I know that static > linking in Linux sucks pretty hard... This is not dependency of libcxx, i think. It's another C++ ABI like libsupc++, and libc++abi and it is be normal to determined at the level of the profile, because several different ABI in shared libs it way to get bug May be we can coose one abi? and remove USE flags in libcxx and patch clang by default
And what about PDEPEND on libcxx? without libcxx clang -stdlib=libc++ doesn't work at all
(In reply to Oleg Ageev from comment #7) > And what about PDEPEND on libcxx? > without libcxx clang -stdlib=libc++ doesn't work at all Not that anyone I know ever wanted to use '-stdlib=libc++'. We don't force people to install random packages just in case they ever wanted to use a side feature.
(In reply to Michał Górny from comment #8) If we want systemwide-clang https://bugs.gentoo.org/show_bug.cgi?id=408963 we should remove dependency from gcc -stdlib=libstdc++ which turn on by default it's one of dependencies or purpose of systemwide-clang is not remove the dependency?
Following your logic, we'd actually have clang depend on gcc, libcxx and all other C++ libraries it supports. I'm afraid you don't understand the purpose of dependencies and how they affect users.
(In reply to Michał Górny from comment #10) > Following your logic, we'd actually have clang depend on gcc, libcxx and all > other C++ libraries it supports. I'm afraid you don't understand the purpose > of dependencies and how they affect users. yes in present time clang depend on gcc because clang use crtbegin/crtend from gcc, and find path to crt1/crti/crtn from path to gcc, and link to libgcc by default all compiled by them but libcxx don't depend on gcc, we can build libcxx by any C++ compiller, because libcxx use -nodefaultlibs and we can replace -lgcc_s by -lunwind what purpose of use clang as systemwide compiler if we have dependency on gcc in runtime for all compiled by clang package?
Please tell me if I'm wrong but you can't link together two libraries/executables that use different stdc++ implementations, correct?
(In reply to Michał Górny from comment #12) > Please tell me if I'm wrong but you can't link together two > libraries/executables that use different stdc++ implementations, correct? yes, but we talk about systemwide compiler, or not? look at /usr/portage/profile/default/bsd/fbsd/amd64/9.1/clang/make.defaults what CXXFLAGS you see? i don't know who use that profile, but it's not correct because in this profile in package.use.force libcxx have libcxxrt turn on by default and if we want use like that profile in linux we should fix that problem PS: and problem to link several stdc++ implementation not in stdc++ problem in C++ ABI like libsupc++, libcxxrt, libc++abi gcc doesn't support stdc++ implementation switching, but we can use nodefaultlibs and use libc++ in gcc
I was referring purely to dependencies of llvm/clang ebuilds. But as far as I understand, the attached patch works fine only when libcxx is built with USE=libcxxrt, correct? I need either a patch that transparently supports both cases or appropriate change in libcxx.
(In reply to Michał Górny from comment #14) > I need either a patch that transparently supports both cases or appropriate > change in libcxx. we can link libcxxrt to libcxx statically
but if we link statically we need rebuild libcxx after libcxxrt upgrade may be remove separate package for libcxxrt and embed them in libcxx? libcxxrt without libcxx it's no use
(In reply to Oleg Ageev from comment #15) > (In reply to Michał Górny from comment #14) > > I need either a patch that transparently supports both cases or appropriate > > change in libcxx. > we can link libcxxrt to libcxx statically No, static linking is an abuse. If libcxx is a shared library, it should itself link to libcxxrt, shouldn't it?
Excuse me, but when does exactly clang++ fail with undefined references? I've just tried using it and it works fine for me.
(In reply to Michał Górny from comment #17) > it should itself link to libcxxrt, shouldn't it? No, but it's not prefered choise :) I gave a link to documentation of libcxx and there says that "To get around this you'll have to set up your linker yourself (or patch clang)" I don't understand why you think that we can come up with anything else. If we need patch clang only for that choise (USE=libcxxrt) why don't add libcxxrt for clang dependencies and > I need either a patch that transparently supports both cases how do you imagine that? maybe parse 'ldd /usr/lib/libc++.so' output in compile time?
(In reply to Michał Górny from comment #18) > Excuse me, but when does exactly clang++ fail with undefined references? > I've just tried using it and it works fine for me. as example try compile your ebuild of llvm with CXX="clang++ -stdlib=libc++"
Oh, I see. That's case of underlinking AFAIU. In any case, I think libcxx is playing the first fiddle here. It's libcxx that provides the headers that reference libcxxrt, and it's libcxx that should provide clang with information on what libraries to link to. If we're ever going to patch clang for this, it will have to be a patch that was *accepted by clang upstream* and *applied unconditionally*. In this regard, it would either mean that clang must recognize the setup libcxx was built for and adjust to it, or support only one of the two possible configurations.
(In reply to Michał Górny from comment #21) > or support only one of the two possible configurations. i think about that, but configuration not two, also exist libc++abi but libc++abi built only by clang, and require libc++ (only headers), i think it circular dependency :)
it shouldnt be done in clang as it has no clue what libcxx uses as undelying libs. I don't know what failure you are experiencing but libcxx ebuild provides: libc++.so dynamically linked without undefined symbols libc++.a as a linked script to pull in the libs it needs. it's been working quite well here, e.g.: http://gentoo.arcticnetwork.ca/experimental/bsd/freebsd/stages/amd64-fbsd-9.1/clang/ have been built with CC=clang, CXX='clang++ -stdlib=libc++' and llvm is part of these stages... please post the failures
(In reply to Michał Górny from comment #21) > It's libcxx that provides the headers that reference libcxxrt libcxx not provides the headers that referenced to libcxxrt libcxx use libcxxrt only for internal purposes and cxxabi.h not required for library which use libc++ required only shared library also if we unmask libunwind use flag for libcxxrt will be diferent configuration and we need patch clang again becaus we need link with libunwind thereby we have 5 configurations libsupc++ + libgcc_s libcxxrt + libgcc_s libcxxrt + libunwind libc++abi + libgcc_s libc++abi + libunwind
(In reply to Alexis Ballier from comment #23) freebsd and all BSD have diferent tools/toolchain in clang maybe that's why there is no problem? and you build libcxx with libcxxrt?
Created attachment 354038 [details] build.log CC=clang CXX="clang++ -stdlib=libc++" sudo -E ebuild /usr/portage/sys-devel/llvm/llvm-9999-r1.ebuild compile
(In reply to Alexis Ballier from comment #23) > it shouldnt be done in clang as it has no clue what libcxx uses as undelying > libs. > > I don't know what failure you are experiencing but libcxx ebuild provides: > libc++.so dynamically linked without undefined symbols I think it can be because GNU gold is more strict if it comes to symbols and requires executable to link explicitly to all libraries that provide the symbols that it uses. Therefore, if somehow implicitly program uses any of libcxxrt symbols through the libc++ headers it will fail without -lcxxrt.
please try with libcxx{,rt}-9999
(In reply to Alexis Ballier from comment #28) > please try with libcxx{,rt}-9999 same result attach build log?
(In reply to Oleg Ageev from comment #29) > (In reply to Alexis Ballier from comment #28) > > please try with libcxx{,rt}-9999 > same result > attach build log? yes please
(In reply to Alexis Ballier from comment #30) > (In reply to Oleg Ageev from comment #29) > > (In reply to Alexis Ballier from comment #28) > > > please try with libcxx{,rt}-9999 > > same result > > attach build log? > > yes please please attach the build log but also try again after my recent changes to libcxx-9999
(In reply to Alexis Ballier from comment #31) > try again after my recent changes to libcxx-9999 look like it's worked
ok then its fixed in libcxx-0.0_p20130725
