Created attachment 548038 [details] compressed build.log >>> Install libcxx-7.0.0 into /var/tmp/portage/sys-libs/libcxx-7.0.0/image/ category sys-libs * .arm: running multilib-minimal_abi_src_install >>> Working in BUILD_DIR: "/var/tmp/portage/sys-libs/libcxx-7.0.0/work/libcxx-7.0.0.src-.arm" [0/1] Install the project... -- Install configuration: "RelWithDebInfo" -- Installing: /var/tmp/portage/sys-libs/libcxx-7.0.0/image/usr/include/c++/v1/cxxabi.h CMake Error at cmake_install.cmake:40 (file): file INSTALL cannot find "/var/tmp/portage/sys-libs/libcxx-7.0.0/work/libcxx-7.0.0.src-.arm/include/c++build/bits/c++config.h". The file is present at almost exactly that folder, but with a double of bits/bits in the path :-) /var/tmp/portage/sys-libs/libcxx-7.0.0/work/libcxx-7.0.0.src-.arm/include/c++build/bits/bits/c++config.h libcxx-6.0.1 is not affected
If you move all header files from that folder from bits/bits/ to bits/, the merge can be finished via ebuild $(equery w libcxx) merge. But thats rather unprofessional.
Is this with cross?
its within a qemu-chroot, hence the -j12
Created attachment 548042 [details] output of emerge --info Forgot to attach emerge.log If you want to me to verify this on native hardware, you'll have to wait till tomorrow
I'm now seeing the exact same issue on ~amd64 (cannot find /tmp/portage/sys-libs/libcxx-7.0.0/work/libcxx-7.0.0.src-abi_x86_64.amd64/include/c++build/bits/c++config.h, file exists under "bits/bits"). This is not a cross-compile. Note specifically that USE="-libcxxabi -libcxxrt" (that is, this is being built against gcc's libsupc++). The part of the cmake config that appears to potentially be at fault (cmake/Modules/HandleLibCXXABI.cmake; the call to setup_abi_lib when LIBCXX_CXX_ABI_LIBNAME=libsupc++) is only run under these conditions.
My useflags from arm are: =sys-libs/libcxx-7 USE="-libcxxabi -libunwind static-libs -libcxxrt -test" are these the same as yours?
Hmm, this is configuration I didn't test indeed. Lemme see if -9999 is broken as well.
Ok, I can reproduce it with -9999. I'm gonna ping Eric about it.
Bisected that to: commit f48515b28b423e5387399524a7aef53c51810f59 Author: Petr Hosek <phosek@chromium.org> Date: Tue Jun 12 03:10:02 2018 +0000 Reland "Use custom command and target to install libc++ headers" Using file(COPY FILE...) has several downsides. Since the file command is only executed at configuration time, any changes to headers made after the initial CMake execution are ignored. This can lead to subtle errors since the just built Clang will be using stale libc++ headers. Furthermore, since the headers are copied prior to executing the build system, this may hide missing dependencies on libc++ from other LLVM components. This changes replaces the use of file(COPY FILE...) command with a custom command and target which addresses all aforementioned issues and matches the implementation already used by other LLVM components that also install headers like Clang builtin headers. Differential Revision: https://reviews.llvm.org/D44773 git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334468 91177308-0d34-0410-b5e6-96231b3b80d8
There's a patch @ https://reviews.llvm.org/D52762 (it should work fine via /etc/portage/patches/sys-libs/libcxx). I've tested it and it fixed the immediate issue for me (there's a header mismatch if you enable 32-bit ABI though).
Created attachment 549464 [details] compressed build logs So I wanted to switch back to llvm/clang-7 today (I rolled back to 6 when I hit this) I can confirm, that USE="-libcxxabi -libcxxrt" for libcxx-7.0.0 builds now when the patch is applied. It also builds with the patch applied and clang being used, while there is USE="libcxxabi libcxxrt" But I ran into some linker warnings for compiler-rt, compiler-rt-sanitizers, libcxx and libcxxabi; and I really don't have a clue if these are caused by the patch? The logs are attached, also the output of emerge -auvND world for you to see if the deps are pulled in a wrong order maybe? For the multilib problems, have you already opened a new bug? Cause, as the patch will be part of 7.0.1, it will wash down in the end.
I've fixed the multilib problem yesterday, and I'm going to test backporting the patch today.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5c39e60eb1090bb54f673f7ab03eb8edaecf32e3 commit 5c39e60eb1090bb54f673f7ab03eb8edaecf32e3 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-10-05 18:36:13 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-10-05 18:48:32 +0000 sys-libs/libcxx: Backport libsupc++ build fix to 7.0.0 Closes: https://bugs.gentoo.org/667174 Signed-off-by: Michał Górny <mgorny@gentoo.org> .../files/libcxx-7.0.0-libsupcxx-install.patch | 32 ++++++++++++++++++++++ sys-libs/libcxx/libcxx-7.0.0.ebuild | 4 +++ 2 files changed, 36 insertions(+)
Thanks for taking care of this, I'll open a new bug for the linker warnings(?)
