Created attachment 720783 [details] compressed build log I ran into this the other day, when I had USE="-crypt" in my hosts make.conf (for reasons I forgot) here is the error from the build log: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-11.1.0-r1/work/gcc-11.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:144:10: fatal error: crypt.h: No such file or directory 144 | #include <crypt.h> | ^~~~~~~~~ compilation terminated. make[4]: *** [Makefile:615: sanitizer_platform_limits_posix.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... I solved this by removing the USE="-crypt" from the hosts make.conf, but I'm unsure about what to do now, with the new changes ahead. Since this is only a chroot to test gcc-11 with, I already switched over to a hosts sys-libs/glibc without the crypt useflag. Should I add +crypt for the cross-glibc then - or is that not a longterm problem solver? I might guess the useflag will be removed, once the switch is complete. cross toolchain is: sys-devel/binutils-2.35.2 sys-kernel/linux-headers-5.10 sys-libs/glibc-2.33 sys-devel/gcc-11.1.0-r1 the full build log is attached as compressed gz
Created attachment 720786 [details] output from emerge --info (host)
current workaround: emerge -pv cross-aarch64-unknown-linux-gnu/glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] cross-aarch64-unknown-linux-gnu/glibc-2.33-r1:2.2::crossdev USE="crypt* multiarch ssp static-libs -audit -caps -cet -compile-locales -custom-cflags -doc -gd -headers-only -multilib -multilib-bootstrap -nscd -profile (-selinux) -static-pie -suid -systemtap -test -vanilla" 0 KiB
Was libxcrypt[system] installed in this case?
yes, this was done in a chroot where I already performed the upgrade to libxcrypt[system] for the host. but the bug can also be triggered on a host where that move hasn't been made, simply by passing over USE="-crypt" to the cross-glibc. I did this accidentially via hosts make.conf a few days ago.
Have you tried using sys-devel/crossdev to merge the cross-compiler in? I just manually migrated my developer machine over to libxcrypt, and rebuilt my cross-compiler target (mips64) and it did not have any issues. I did mask the 'crypt' USE for my cross-compiler target in /etc/portage/package.use and /etc/portage/profile/package.use.force, just like for sys-libs/glibc beforehand. Make sure you're following this guide as well if you want to migrate early: https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
Just tried with cross aarch64 and stage2 went without issues on my libxcrypt system (both host and cross glibc have -crypt). I find it curious that in your case it's trying to build libsanitizer at all, it doesn't for me. If anything crossdev tries to add -sanitize to package.use
here are the final useflags of cross-glibc and cross-gcc Calculating dependencies... done! [ebuild R ~] cross-aarch64-unknown-linux-gnu/glibc-2.33-r1:2.2::crossdev USE="crypt multiarch ssp static-libs -audit -caps -cet -compile-locales -custom-cflags -doc -gd -headers-only -multilib -multilib-bootstrap -nscd -profile (-selinux) -static-pie -suid -systemtap -test -vanilla" 0 KiB [ebuild R ~] cross-aarch64-unknown-linux-gnu/gcc-11.1.0-r1:11::crossdev USE="cxx fortran nls nptl openmp pch pie sanitize ssp -ada -custom-cflags -d -debug -doc (-fixed-point) -go -graphite -hardened -jit -libssp -lto -multilib -objc -objc++ -objc-gc -pgo -systemtap -test -valgrind -vanilla -vtv -zstd" 0 KiB I haven't touched any of those useflags, so you think this is a bug in crossdev where it should be USE="-sanitize" for cross-gcc?
From package.use/cross-aarch64-unknown-linux-gnu (created by crossdev): cross-aarch64-unknown-linux-gnu/gcc -vtv -selinux -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc -fortran -go -jit -cxx -mpx -openmp -sanitize -vtv -multilib Maybe you have something conflicting.
so here is my command to crossdev: crossdev -S aarch64-unknown-linux-gnu --gcc 11.1.0-r1 --ov-output /var/lib/layman/crossdev/ --init-target - * crossdev version: 20210621 * Host Portage ARCH: amd64 * Host Portage System: x86_64-pc-linux-gnu (i686-pc-linux-gnu x86_64-pc-linux-gnu) * Target Portage ARCH: arm64 * Target System: aarch64-unknown-linux-gnu * Stage: 4 (C/C++ compiler) * USE=multilib: no * Target ABIs: arm64 * binutils: binutils-[stable] * gcc: gcc-11.1.0-r1 * headers: linux-headers-[stable] * libc: glibc-[stable] * CROSSDEV_OVERLAY: /var/lib/layman/crossdev/ * PORT_LOGDIR: /var/log/portage * PORTAGE_CONFIGROOT: / * Portage flags: but still sanitize is not disabled in package.use: cat /etc/portage/package.use/cross-aarch64-unknown-linux-gnu cross-aarch64-unknown-linux-gnu/binutils -multilib cross-aarch64-unknown-linux-gnu/linux-headers -selinux -multilib cross-aarch64-unknown-linux-gnu/glibc -selinux -libraries -multilib cross-aarch64-unknown-linux-gnu/gcc -vtv -selinux -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc -multilib and nothing changed anywhere else inside of hosts /etc/portage: /etc/portage # grep -r sanitize
it's odd indeed that you build the sanitizer have you set a specific profile inside your crossdev environment? see /usr/aarch64-unknown-linux-gnu/etc/portage
Did you mean to ask for the target of the make.profile symlink in that folder? That is the default symlink, pointing to /var/db/repos/gentoo/profiles/embedded I also think that this problem is specific to gcc-11, I had the -crypt for longer period of time in my hosts make.conf, and it didn't trigger any problems with gcc-10 or gcc-9 based toolchains. Will double check in the evening.
Created attachment 721215 [details] hosts make.conf
hosts profile is [1] default/linux/amd64/17.1 (stable) *
I can confirm, same issue here: fatal error: crypt.h: No such file or directory 144 | #include <crypt.h> As glibc crypt support will be gone at some point, I did: aarch64-unknown-linux-gnu-emerge virtual/libcrypt libxcrypt system flag was set and gcc was able to compile with cross-aarch64-unknown-linux-gnu/glibc -crypt
(In reply to Cănărău Constantin from comment #14) > I can confirm, same issue here: > fatal error: crypt.h: No such file or directory > 144 | #include <crypt.h> > > As glibc crypt support will be gone at some point, I did: > > aarch64-unknown-linux-gnu-emerge virtual/libcrypt > > libxcrypt system flag was set and gcc was able to compile with > cross-aarch64-unknown-linux-gnu/glibc -crypt so when stage2 cross-gcc failed, you emerged libxcrypt[system] into the half bootstrapped rootfs, and then continued with building the stage2 cross-gcc?
(In reply to tt_1 from comment #15) > > so when stage2 cross-gcc failed, you emerged libxcrypt[system] into the half > bootstrapped rootfs, and then continued with building the stage2 cross-gcc? No, I did that on an existing system. cross-aarch64-unknown-linux-gnu/glibc and cross-aarch64-unknown-linux-gnu/gcc were compiled before. Changed glibc to -crypt according to: https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation cross-aarch64-unknown-linux-gnu/glibc was recompiled automatically with success. I tried to compile cross-aarch64-unknown-linux-gnu/gcc to see if everything is alright and it fail. Then I tried the workaround with aarch64-unknown-linux-gnu-emerge virtual/libcrypt which pulled, among other dependencies, libxcrypt[system]
(In reply to Cănărău Constantin from comment #16) > (In reply to tt_1 from comment #15) > > > > so when stage2 cross-gcc failed, you emerged libxcrypt[system] into the half > > bootstrapped rootfs, and then continued with building the stage2 cross-gcc? > > No, I did that on an existing system. > cross-aarch64-unknown-linux-gnu/glibc and > cross-aarch64-unknown-linux-gnu/gcc were compiled before. > > Changed glibc to -crypt according to: > https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation > > cross-aarch64-unknown-linux-gnu/glibc was recompiled automatically with > success. > I tried to compile cross-aarch64-unknown-linux-gnu/gcc to see if everything > is alright and it fail. > > Then I tried the workaround with aarch64-unknown-linux-gnu-emerge > virtual/libcrypt which pulled, among other dependencies, libxcrypt[system] this bug is about the failure in bootstrapping the cross-gcc stage2 compiler with crossdev, populating the rootfs is another story. I will test it, when this bug has been dealt with.
Unfortunately I can't reproduce this here. Crossdev works just fine. (~amd64 chroot) crossdev ~ # crossdev -S --target aarch64-unknown-linux-gnu --gcc 11.1.0-r2 - * crossdev version: 20210621 * Host Portage ARCH: amd64 * Host Portage System: x86_64-pc-linux-gnu (i686-pc-linux-gnu x86_64-pc-linux-gnu) * Target Portage ARCH: arm64 * Target System: aarch64-unknown-linux-gnu * Stage: 4 (C/C++ compiler) * USE=multilib: no * Target ABIs: arm64 * binutils: binutils-[stable] * gcc: gcc-11.1.0-r2 * headers: linux-headers-[stable] * libc: glibc-[stable] * CROSSDEV_OVERLAY: /usr/local/portage/crossdev * PORT_LOGDIR: /var/log/portage * PORTAGE_CONFIGROOT: / * Portage flags: * leaving metadata/layout.conf alone in /usr/local/portage/crossdev * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-gcc-stage2.log * Emerging cross-gcc-stage2 ... [ ok ] (~amd64 chroot) crossdev ~ #
Do yo have USE=sanitize in make.conf? That is a prerequisite to get stage2 to attempt to build it.
USE="+sanitize" is picked up from profile I believe, isn't it?
(In reply to tt_1 from comment #9) > but still sanitize is not disabled in package.use: > [...] How old are those package.use files that don't disable sanitize? I guess it's possible crossdev is not updating them. I've been testing with a blank state, so may be why can't reproduce.
latest changes in toolchain.eclass solve this bug for native toolchains: https://github.com/gentoo/gentoo/commit/85c6de2213e35965d2e7c79c06d9e9b9d6af7e0d do we have to patch crossdev, or what is the most likely outcome here?
On ~arch # USE=-crypt crossdev aarch64-unknown-linux-gnu is enough to trigger sanitize build against /usr/$CTARGET without crypt.h crossdev ignores DEPENDs for gcc and generally assumes low/no dependencies on target headers. Unfortunately USE=sanitize pulls in crypt.h (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85c6de2213e35965d2e7c79c06d9e9b9d6af7e0d would be effective for native builds). The simplest workaround would be to disable USE=sanitize in gcc-stage2 in crossdev (the same way we do it for stage1) and rely on user to install libxcrypt later.
Until crossdev is fixed # USE=-sanitize crossdev aarch64-unknown-linux-gnu or # USE=crypt crossdev aarch64-unknown-linux-gnu should work as a workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=5d7a0f2bd35ea01f24883bc2e21e1bda5458584e commit 5d7a0f2bd35ea01f24883bc2e21e1bda5458584e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-07-17 23:37:58 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-07-17 23:37:58 +0000 crossdev: disable USE=sanitize for gcc-stage2 as well Reported-by: tt_1 Bug: https://bugs.gentoo.org/799707 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=14ecd1b309eafd75602966418ce9600c0e99cf0e commit 14ecd1b309eafd75602966418ce9600c0e99cf0e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-07-17 23:51:09 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-07-17 23:51:55 +0000 sys-devel/crossdev: bump up to 20210718 Single new change: - disable USE=sanitize for gcc-stage2 as well Reported-by: tt_1 Closes: https://bugs.gentoo.org/799707 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20210718.ebuild | 35 +++++++++++++++++++++++++++++ sys-devel/crossdev/crossdev-99999999.ebuild | 2 +- 3 files changed, 37 insertions(+), 1 deletion(-)
