Without the lib -> lib64 symlink, crossdev's stage 2 GCC fails to find crti.o in /usr/lib64 Simply adding this symlink manually fixes it.
Please attach the entire build log(s) to this bug report. Please post your `emerge --info` output in a comment.
Don't have build logs anymore, since it succeeded with the lib symlink in place. emerge --info is too long for comments, so I'll attach it...
Created attachment 526786 [details] emerge --info
Please provide crossdev build log.
Tried in a fresh chroot today: sf / # FEATURES="-strict -stricter -test" crossdev -S -t powerpc64le-foo-linux-gnu - * crossdev version: 20180302 * Host Portage ARCH: x86 * Target Portage ARCH: ppc64 * Target System: powerpc64le-foo-linux-gnu * Stage: 4 (C/C++ compiler) * ABIs: ppc64 * binutils: abinutils- * gcc: agcc- * headers: alinux-headers- * libc: aglibc- * CROSSDEV_OVERLAY: /co * PORT_LOGDIR: /var/log/portage * PORTAGE_CONFIGROOT: / * Portage flags: * enabling thin-manifests due to /bound/portage * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-linux-headers-quick.log * Emerging cross-linux-headers-quick ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-glibc-headers.log * Emerging cross-glibc-headers ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /var/log/portage/cross-powerpc64le-foo-linux-gnu-gcc-stage2.log * Emerging cross-gcc-stage2 ...
(In reply to Sergei Trofimovich from comment #5) > Tried in a fresh chroot today: > * Emerging cross-gcc-stage2 ... * Emerging cross-gcc-stage2 ... [ ok ]
Created attachment 526818 [details] Output from crossdev crossdev -S -t powerpc64le-foo-linux-gnu
Created attachment 526820 [details] /var/log/portage/cross-powerpc64le-foo-linux-gnu-gcc-stage2.log.xz
Aha, here globally enabled USE=multilib is at least the breakage trigger. By default crossdev uses 'embedded' profile. This profile has no multilib tweaks. As a result DEFAULT_ABI, ABI, MULTILIB_ABI leak out into cross-${CTARGET}/gcc with default library paths incompatible with glibc ebuild multilib layout. glibc also did not like that layout. For example /usr/powerpc64le-foo-linux-gnu/lib64/ld64.so.1 is a broken link. The workaround is to disable multilib for crossdev: # USE=-multilib crossdev -S -t powerpc64le-foo-linux-gnu Better way to do it would be to update crossdev to do the following: 1. detect request for multilib build from within crossdev and fail if crossdev can't handle it sanely 2. Add into crossdev direct support for picking default profile instead of 'embedded'
Despite whatever the logs show, USE=multilib is NOT enabled in any of the installed crossdev packages, according to Portage. The ld64.so.1 thing is probably unrelated: mattst88 gave me a PPC64LE rootfs the other day, and it also has a broken symlink there: lrwxrwxrwx root/root 0 2018-04-06 21:32 lib64/ld64.so.1 -> ../lib64/ld64.so.1
Then I need all the logs from crossdev (not just gcc-stage2). Because build clearly does not fail the same way for me.
Finally managed to reproduce it locally: - unpacked the same default/linux/amd64/17.0/hardened stage3 - applied all USE flags from emerge --info - installed gcc-7.3.0 Didn't investigate much yet. One of things to note is host (and target) binutils is built with USE=multitarget. Worth a short with USE=-multitarget
(In reply to Sergei Trofimovich from comment #12) > Worth a short with USE=-multitarget Did not help.
Failed command here is: /dev/shm/portage/cross-powerpc64le-foo-linux-gnu/gcc-6.4.0-r1/work/build/./gcc/xgcc -B/dev/shm/portage/cross-powerpc64le-foo-linux-gnu/gcc-6.4.0-r1/work/build/./gcc/ -B/usr/powerpc64le-foo-linux-gnu/bin/ -B/usr/powerpc64le-foo-linux-gnu/lib/ -isystem /usr/powerpc64le-foo-linux-gnu/include -isystem /usr/powerpc64le-foo-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fstack-check=no -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o ibm-ldouble_s.o tramp_s.o ppc64-fp_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc /usr/libexec/gcc/powerpc64le-foo-linux-gnu/ld: cannot find crti.o: No such file or directory I think this implies that for non-multilib system gcc expects libraries to reside in /lib (and /usr/lib): -B/usr/powerpc64le-foo-linux-gnu/lib/ Then gcc tries hard to resolve lib64 against non-existing lib/: stat("/usr/powerpc64le-foo-linux-gnu/usr/lib/../lib64/.", 0x7ffc8cd858e0) = -1 ENOENT (No such file or directory) At least glibc itself defines /lib as 32-bit location and /lib64 as 64-bit location: #define GLIBC_DYNAMIC_LINKER32 "%(dynamic_linker_prefix)/lib/ld.so.1" #ifdef LINUX64_DEFAULT_ABI_ELFv2 #define GLIBC_DYNAMIC_LINKER64 \ "%{mabi=elfv1:%(dynamic_linker_prefix)/lib64/ld64.so.1;" \ ":%(dynamic_linker_prefix)/lib64/ld64.so.2}" #else #define GLIBC_DYNAMIC_LINKER64 \ "%{mabi=elfv2:%(dynamic_linker_prefix)/lib64/ld64.so.2;" \ ":%(dynamic_linker_prefix)/lib64/ld64.so.1}" #endif Thus my hunch would be: - glibc is installed correctly into /lib64 - gcc (or binutils?) picked wrong location to offset against as ${SYSROOT}/usr/lib/../lib64. Normally gcc does it against --libdir= argument but toolchain.eclass does not pass --libdir at all. And gcc's default is: libdir='${exec_prefix}/lib'
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c7684eaa754323674d11a2a6e6e46e5d1e079a45 commit c7684eaa754323674d11a2a6e6e46e5d1e079a45 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-09 06:23:09 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-09 06:23:25 +0000 sys-libs/glibc: fix USE=headers-only install for powerpc64le target glibc-2.27 needs 2 more sanity checks from native compiler to pass configure: libc_cv_compiler_powerpc64le_binary128_ok=yes libc_cv_target_power8_ok=yes Notices when tried clean toolchain botstrap for bug #652724 Bug: https://bugs.gentoo.org/652724 Package-Manager: Portage-2.3.28, Repoman-2.3.9 sys-libs/glibc/glibc-2.27-r1.ebuild | 2 ++ sys-libs/glibc/glibc-9999.ebuild | 2 ++ 2 files changed, 4 insertions(+)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=78d402061875170020c6ad4a29a45296007372e4 commit 78d402061875170020c6ad4a29a45296007372e4 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-10 07:00:10 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-10 07:00:10 +0000 crossdev: unconditionally create /usr/${CTARGET}/{lib,usr/lib} Copying note as-is here: ``` Create directories usually created by sys-apps/baselayout Why we do that at all: For multilib-aware targets (ppc64, s390x, sparc64, x86_64) Gentoo normally uses libdir=lib64. For crossdev it means /lib and /usr/lib does not get created at all but gcc relies on their presence by refering to =/lib64 as =/usr/lib/../lib64 when builds itself (see https://bugs.gentoo.org/652724) Thus we create non-symlinked layout early. ``` Before the change 'crossdev -t powerpc64le-foo-linux-gnu' failed at gcc-stage2 as: ``` ... \ -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 \ -o ./libgcc_s.so.1.tmp \ ... \ /usr/libexec/gcc/powerpc64le-foo-linux-gnu/ld: cannot find crti.o: No such file or directory access("/usr/powerpc64le-foo-linux-gnu/usr/lib/../lib64/crti.o", R_OK) = -1 ENOENT (No such file or directory) ``` The change adds empty directory '/usr/powerpc64le-foo-linux-gnu/usr/lib' to make ld probing finally find 'crti.o' in $SYSROOT. Reported-by: Luke-Jr Bug: https://bugs.gentoo.org/652724 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 14 ++++++++++++++ 1 file changed, 14 insertions(+)}
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79e2aaafe727f09b7b6a34164a8e88bad6afcdd0 commit 79e2aaafe727f09b7b6a34164a8e88bad6afcdd0 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-10 07:51:54 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-10 07:51:54 +0000 sys-devel/crossdev: bump up to 20180410 Closes: https://bugs.gentoo.org/652724 Bug: https://bugs.gentoo.org/147155 Bug: https://bugs.gentoo.org/650100 Package-Manager: Portage-2.3.28, Repoman-2.3.9 sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20180410.ebuild | 39 +++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=88796dc3eb02643799f661d38386bede0109cef2 commit 88796dc3eb02643799f661d38386bede0109cef2 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-07-19 00:38:04 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-07-19 00:38:24 +0000 sys-libs/glibc: preserve /usr/lib witk keepdir Today crossdev does not install baselayout into /usr/${CTARGET}. As a result /usr/${CTARGET}/usr/lib was not created by any ebuilds. glibc ebuild used to create /usr/lib but recently added install-qa-check.d/95empty-dirs by portage broke that assumption. This change uses keepdir to ensure presense of /usr/${CTARGET}/usr/lib. Longer term crossdev will attempt to use baselayout. Reported-by: Vadim A. Misbakh-Soloviov <git@mva.name> Bug: https://bugs.gentoo.org/652724 Package-Manager: Portage-2.3.43, Repoman-2.3.10 sys-libs/glibc/glibc-2.27-r5.ebuild | 6 ++---- sys-libs/glibc/glibc-9999.ebuild | 6 ++---- 2 files changed, 4 insertions(+), 8 deletions(-)
