I'm trying to bootstrap on a POWER system (ppc64le) running CentOS8. This initially failed because there is no suitable profile. In order to fix that, I've created a directory $EPREFIX/var/db/repos/gentoo/profiles/default/linux/ppc64le/17.0/prefix/kernel-3.2+, with a file eapi and parent. The latter contains: .. ../../../../../../features/prefix/standalone This solves the profile issue, and allows stage1 to continue. A bit later on it crashed again, because baselayout-prefix doesn't have ppc64 support. I've added that to the keywords, and then it went on till the build of binutils. This failed, because glibc had created a circular symlink: gentoo/lib64/ld64.so.1 -> ../lib64/ld64.so.1 I was able to fix this by changing the abi list in the glibc ebuild file. According to https://sourceware.org/glibc/wiki/ABIList#powerpc, the correct ld.so filename for ppc64le should be /lib64/ld64.so.2. So, I used the existing case statement for arm64 to also distinguish between ppc64 big and little endian. Now the bootstrap successfully completes stages 1 and 2, and builds things like glibc, binutils, gcc, and, finally, gawk in stage 3. However, it then fails while building ncurses. I get lots of these: config.status: creating Makefile config.status: creating include/ncurses_cfg.h gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) Appending rules for normal model (ncurses: ticlib+termlib+ext_tinfo) gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) And I can't figure out what's causing this... Reproducible: Always Steps to Reproduce: 1.Bootstrap on a ppc64le system with the steps described in the description field Actual Results: Lots of these errors in stage 3, while building ncurses: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) $ ./tmp/usr/bin/emerge --info setlocale: unsupported locale setting setlocale: unsupported locale setting Portage 2.3.100-prefix (python 3.7.7-final-0, default/linux/ppc64le/17.0/prefix/kernel-3.2+, gcc-10.2.0, unavailable, 4.18.0-193.28.1.el8_2.ppc64le ppc64le) ================================================================= System uname: Linux-4.18.0-193.28.1.el8_2.ppc64le-ppc64le-with-centos-8.2.2004-Core KiB Mem: 15681024 total, 6211456 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 29 Oct 2020 00:45:01 +0000 Head commit of repository gentoo: 468e97372af89e2f8d94def9709149983f3830e6 sh bash 5.0_p18 ld GNU ld version 2.30-73.el8 app-shells/bash: 5.0_p18::gentoo sys-devel/binutils: 2.35.1::gentoo sys-devel/gcc: 10.2.0-r2::gentoo sys-devel/gcc-config: 2.3.2::gentoo Repositories: gentoo location: /home/bob/gentoo/var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.prefix.bitzolder.nl/gentoo-portage-prefix priority: -1000 sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: yes sync-rsync-verify-max-age: 24 ACCEPT_KEYWORDS="ppc64 ~ppc64" ACCEPT_LICENSE="@FREE" CBUILD="powerpc64le-unknown-linux-gnu" CFLAGS="-O2 -pipe -O2 -pipe" CHOST="powerpc64le-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/gentoo-release /etc/terminfo" CXXFLAGS="-O2 -pipe -O2 -pipe" DISTDIR="/home/bob/gentoo/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles force-prefix ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sfperms strict unknown-features-warn unmerge-logs unmerge-orphans unprivileged" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/home/bob/gentoo/tmp/var/cache/binpkgs" PORTAGE_CONFIGROOT="/home/bob/gentoo/tmp/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/home/bob/gentoo/tmp/var/tmp" USE="bootstrap bzip2 cli crypt dri iconv internal-glib ipv6 libglvnd ncurses nptl openmp pam ppc64 prefix readline seccomp split-usr ssl tcpd unicode zlib" ABI_PPC="64" ADA_TARGET="gnat_2018" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby25 ruby26" USERLAND="GNU" VIDEO_CARDS="fbdev mga nv r128 radeon dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hmmm, this is a RAP problem, somehow related to building the libc. This needs one of the RAP people to comment on this, or alternatively (since your host is fairly recent) try exporting PREFIX_DISABLE_RAP=yes before running bootstrap-prefix.sh
(In reply to Fabian Groffen from comment #1) > Hmmm, this is a RAP problem, somehow related to building the libc. This > needs one of the RAP people to comment on this, or alternatively (since your > host is fairly recent) try exporting PREFIX_DISABLE_RAP=yes before running > bootstrap-prefix.sh Thanks for the suggestion! I've just tried this, but unfortunately it failed quite early in stage3, with an error I don't understand: GCC is complaining about a missing mpc.h, while the installation of MPC succeeded and the header file is available in $EPREFIX/usr/include. Do you maybe have an idea about why it cannot be found? I'll attach the stage3 log.
Created attachment 675835 [details] Stage3 log file
Did it go all the way without issues up until stage3, or did you restart the bootstrap with RAP disabled? In case of the latter, I think stuff is slightly messed up. (In the former too, but the latter I can explain right here and now ;) )
I started from scratch, but it did fail in stage 1 due to a missing profile, basically because there was no var/db/repos/gentoo/profiles/prefix/linux/ppc64le/. So I copied the one from ppc64, and changed the make.defaults to: # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 ARCH="ppc64le" CHOST="powerpc64le-pc-linux-gnu" # The base profile sets ACCEPT_KEYWORDS=ppc64 and we don't have that in prefix. # Eventually, ~* should be removed once someone is motivated for this arch ACCEPT_KEYWORDS="-ppc64 ~ppc64-linux ~*" # We don't have lib64 in prefix so, remove it here. SYMLINK_LIB="" LIBDIR_ppc64="lib" Then I restarted it from there.
(In reply to Bob Dröge from comment #5) > I started from scratch, but it did fail in stage 1 due to a missing profile, > basically because there was no > var/db/repos/gentoo/profiles/prefix/linux/ppc64le/. So I copied the one from > ppc64, and changed the make.defaults to: > > # Copyright 1999-2012 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > ARCH="ppc64le" > CHOST="powerpc64le-pc-linux-gnu" > # The base profile sets ACCEPT_KEYWORDS=ppc64 and we don't have that in > prefix. > # Eventually, ~* should be removed once someone is motivated for this arch > ACCEPT_KEYWORDS="-ppc64 ~ppc64-linux ~*" > > # We don't have lib64 in prefix so, remove it here. > SYMLINK_LIB="" > LIBDIR_ppc64="lib" > > > Then I restarted it from there. I think at the least you need arch to just be ppc64 (compare with non prefix profiles).
Thanks Sam. I tried it a few more times, for instance by only setting ARCH, and also by setting some more variables that I found in var/db/repos/gentoo/profiles/arch/powerpc/ppc64/make.defaults; is that what you were referring to? However, in all cases it keeps failing with the same error: In file included from /home/bob/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r3/work/gcc-10.2.0/gcc/c/c-decl.c:53: /home/bob/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r3/work/gcc-10.2.0/gcc/builtins.h:23:10: fatal error: mpc.h: No such file or directory 23 | #include <mpc.h> While that file does just exist in ~/gentoo/usr/include... This is the make.defaults from my last attempt; are there any obvious issues with it (not sure which variables do need ppc64le and which ones just ppc64)? # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 ARCH="ppc64" #CHOST="powerpc64-pc-linux-gnu" CHOST="powerpc64le-unknown-linux-gnu" CFLAGS="-O2 -pipe" CXXFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" FCFLAGS="${CFLAGS}" CHOST_ppc64="powerpc64le-unknown-linux-gnu" CHOST_ppc="powerpcle-unknown-linux-gnu" USE="ibm" MULTILIB_ABIS="ppc64" DEFAULT_ABI="ppc64" KERNEL_ABI="ppc64" PROFILE_ARCH="ppc64" ABI="ppc64" #CFLAGS_ppc64="-m64" LDFLAGS_ppc64="-m elf64ppc" CHOST_ppc64="powerpc64le-unknown-linux-gnu" CFLAGS_ppc="-m32" LDFLAGS_ppc="-m elf32ppc" CHOST_ppc="powerpc-unknown-linux-gnu" # Michał Górny <mgorny@gentoo.org> (2014-06-27) # Make the ABI flag implicit for compatibility with native ebuilds. IUSE_IMPLICIT="abi_ppc_64" # Donnie Berkholz <dberkholz@gentoo.org> (2006-08-18) # Defaults for video drivers VIDEO_CARDS="fbdev mga nv r128 radeon" # Enable abi_ppc_64 for packages that don't have it forced. ABI_PPC="64" # The base profile sets ACCEPT_KEYWORDS=ppc64 and we don't have that in prefix. # Eventually, ~* should be removed once someone is motivated for this arch ACCEPT_KEYWORDS="-ppc64 ~ppc64-linux ~*" # We don't have lib64 in prefix so, remove it here. SYMLINK_LIB="" LIBDIR_ppc64="lib"
Thanks for that little excerpt. It shows gcc-10.2.0 whereas the "prefix" version we have is 10.1.0. I had this suspicion yesterday already, you're not using the prefix tree, but the regular tree. Did you do anything in this regard? RAP bootstraps take the regular tree, but it is incompatible with "prefix".
Ah, yes, good catch :-) We were using a slightly modified version of the script that allows us to use the same snapshot version for all Prefix installation (we build them for several architectures), so I was still using that same snapshot here as well. I'm now retrying it with the latest default version of the script.
Now the build of ncurses during stage2 fails with the following message: * gen_usr_ldscript: Please migrate to usr-ldscript.eclass /home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/temp/environment: line 1767: scanelf: command not found * ERROR: sys-libs/ncurses-6.1-r3::gentoo_prefix failed (install phase): * unable to read SONAME from libncurses.so * * Call stack: * ebuild.sh, line 125: Called src_install * environment, line 3478: Called multilib-minimal_src_install * environment, line 2608: Called multilib_foreach_abi 'multilib-minimal_abi_src_install' * environment, line 2841: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 2495: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 2493: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_install' * environment, line 847: Called multilib-minimal_abi_src_install * environment, line 2598: Called multilib_src_install * environment, line 3075: Called gen_usr_ldscript '-a' 'ncurses' 'ncursesw' 'tinfow' 'tinfo' * environment, line 1768: Called die * The specific snippet of code: * [[ -z ${tlib} ]] && die "unable to read SONAME from ${lib}"; * * If you need support, post the output of `emerge --info '=sys-libs/ncurses-6.1-r3::gentoo_prefix'`, * the complete build log and the output of `emerge -pqv '=sys-libs/ncurses-6.1-r3::gentoo_prefix'`. * The complete build log is located at '/home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/temp/build.log'. * The ebuild environment file is located at '/home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/temp/environment'. * Working directory: '/home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/work/ncurses-6.1-.ppc64' * S: '/home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/work/ncurses-6.1' * QA Notice: command not found: * * /home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/temp/environment: line 3435: !multilib_is_native_abi: command not found * /home/bob/gentoo/tmp/var/tmp/portage/sys-libs/ncurses-6.1-r3/temp/environment: line 1767: scanelf: command not found
oh, gen_usr_ldscript shouldn't be called any more I think ... bit hacky, but can you look up $EPREFIX/var/db/repos/gentoo/eclass/toolchain-funcs.eclass, and in gen_usr_ldscript() function there, just put a return right before/after the ewarn to migrate? You can just resume the build after that by rerunning the script
actually, can you confirm this bit is in your version: local lib libdir=$(get_libdir) output_format="" auto=false suffix=$(get_libname) [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/ tc-is-static-only && return use prefix && return the last line should make sure it returns on Prefix, always. I think your profile isn't setup correctly. You need a copy of profiles/prefix/linux/ppc64 (because you need to eventually end up inheriting features/prefix -- use.mask and use.force set USE=prefix)
Hmm, thought I had done something like that before, but probably in a different directory. I've tried your suggestion now, and the bootstrap got quite far. At some point it failed during stage 3 because sys-libs/librtas was masked due to missing keywords. I solved that by adding ~ppc64-linux to its ebuild file, but it immediately gives another error: - sys-kernel/linux-headers-5.9::gentoo_prefix (masked by: package.mask, missing keyword) /home/bob/gentoo/var/db/repos/gentoo/profiles/prefix/linux/package.mask: # Michael Haubenwallner <haubi@gentoo.org> (2019-01-08) # Prefix Guest does use host libc and host kernel's headers, # hence packages should depend on virtual/os-headers instead. Should I try to unmask it, or should this be solved in another way? Thanks for all your quick support by the way, really appreciated!
I'll add a profile for you, once you tell me what worked :) haubi's mask is correct, I don't know what sys-libs/librtas is, but it should depend on virtual/os-headers. A quick hack will be to put in EPREFIX/etc/portage/package.provided: sys-kernel/linux-headers-5.9 This is really fugly, but if it helps you get further, then we can sort it afterwards.
That would be nice! :-) I've tried this, and now I get the following: Calculating dependencies .... done! [nomerge ] sys-devel/gettext-0.21::gentoo_prefix USE="cxx ncurses openmp (-acl) -cvs -doc -emacs -git -java -nls -static-libs" [nomerge ] dev-libs/expat-2.2.10::gentoo_prefix USE="unicode -examples (-split-usr) -static-libs" [nomerge ] sys-devel/libtool-2.4.6-r6:2::gentoo_prefix USE="-vanilla" [nomerge ] sys-devel/automake-1.16.3-r1:1.16::gentoo_prefix USE="-test" [nomerge ] dev-lang/perl-5.30.3-r1:0/5.30::gentoo_prefix USE="-berkdb -debug -doc -gdbm -ithreads -minimal" [nomerge ] app-admin/perl-cleaner-2.28::gentoo_prefix [nomerge ] sys-apps/portage-3.0.10.2::gentoo_prefix USE="native-extensions -apidoc -build -doc -gentoo-dev (-ipc) -rsync-verify (-selinux) -xattr" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" [nomerge ] dev-lang/python-3.7.8-r2:3.7/3.7m::gentoo_prefix USE="ipv6 ncurses readline ssl xml (-aqua) -bluetooth -build -examples -gdbm -hardened -libressl -sqlite -test -tk -wininst" [ebuild N ] sys-apps/util-linux-2.36.1-r1::gentoo_prefix USE="cramfs logger ncurses readline suid unicode (-audit) -build -caps -cryptsetup -fdformat -hardlink -kill -nls (-pam) -python (-selinux) -slang (-split-usr) -static-libs -su (-systemd) -test -tty-helpers (-udev)" PYTHON_TARGETS="python3_7 -python3_6 -python3_8 -python3_9" 5110 KiB [ebuild N ] virtual/libcrypt-1-r1:0/1::gentoo_prefix USE="static-libs" 0 KiB [ebuild N ] sys-libs/glibc-2.32-r3:2.2::gentoo_prefix USE="(crypt) multiarch ssp (static-libs) (-audit) -caps (-cet) -compile-locales -custom-cflags -doc -gd -headers-only (-multilib) -nscd -profile (-selinux) (-static-pie) -suid -systemtap -test (-vanilla)" 16369 KiB [ebuild N ] app-admin/perl-cleaner-2.28::gentoo_prefix 8 KiB [ebuild N ] sys-apps/portage-3.0.10.2::gentoo_prefix USE="native-extensions -apidoc -build -doc -gentoo-dev (-ipc) -rsync-verify (-selinux) -xattr" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" 0 KiB [ebuild N ] dev-lang/python-3.7.8-r2:3.7/3.7m::gentoo_prefix USE="ipv6 ncurses readline ssl xml (-aqua) -bluetooth -build -examples -gdbm -hardened -libressl -sqlite -test -tk -wininst" 26 KiB [ebuild N ] virtual/perl-File-Temp-0.230.900::gentoo_prefix 0 KiB [ebuild N ] perl-core/File-Temp-0.230.900::gentoo_prefix 74 KiB [ebuild N ] virtual/perl-Test-Harness-3.420.0-r3::gentoo_prefix 0 KiB [ebuild N ] virtual/perl-Data-Dumper-2.174.0-r1::gentoo_prefix 0 KiB [nomerge ] sys-libs/glibc-2.32-r3:2.2::gentoo_prefix USE="(crypt) multiarch ssp (static-libs) (-audit) -caps (-cet) -compile-locales -custom-cflags -doc -gd -headers-only (-multilib) -nscd -profile (-selinux) (-static-pie) -suid -systemtap -test (-vanilla)" [ebuild N ] sys-devel/bison-3.7.4::gentoo_prefix USE="-examples -nls -static -test" 0 KiB [ebuild N ] net-dns/libidn2-2.3.0:0/2::gentoo_prefix USE="-static-libs" 2115 KiB [nomerge ] sys-apps/util-linux-2.36.1-r1::gentoo_prefix USE="cramfs logger ncurses readline suid unicode (-audit) -build -caps -cryptsetup -fdformat -hardlink -kill -nls (-pam) -python (-selinux) -slang (-split-usr) -static-libs -su (-systemd) -test -tty-helpers (-udev)" PYTHON_TARGETS="python3_7 -python3_6 -python3_8 -python3_9" [ebuild N ] sys-libs/librtas-2.0.2-r1::gentoo_prefix USE="-static-libs" 90 KiB [ebuild N ] sys-devel/gettext-0.21::gentoo_prefix USE="cxx ncurses openmp (-acl) -cvs -doc -emacs -git -java -nls -static-libs" 23616 KiB [ebuild N ] dev-libs/libxml2-2.9.10-r3:2::gentoo_prefix USE="ipv6 readline -debug -examples -icu -lzma -python -static-libs -test" PYTHON_TARGETS="python3_7 -python3_6 -python3_8 -python3_9" 5564 KiB [ebuild N ] dev-libs/expat-2.2.10::gentoo_prefix USE="unicode -examples (-split-usr) -static-libs" 416 KiB [ebuild N ] sys-devel/libtool-2.4.6-r6:2::gentoo_prefix USE="-vanilla" 951 KiB [ebuild N ] sys-devel/automake-1.16.3-r1:1.16::gentoo_prefix USE="-test" 1554 KiB [ebuild N ] sys-apps/help2man-1.47.8::gentoo_prefix USE="-nls" 196 KiB [ebuild N ] sys-devel/autoconf-2.69-r5:2.69::gentoo_prefix USE="-emacs" 1438 KiB [ebuild N ] dev-lang/perl-5.30.3-r1:0/5.30::gentoo_prefix USE="-berkdb -debug -doc -gdbm -ithreads -minimal" 12208 KiB [nomerge ] sys-apps/portage-3.0.10.2::gentoo_prefix USE="native-extensions -apidoc -build -doc -gentoo-dev (-ipc) -rsync-verify (-selinux) -xattr" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" [nomerge ] net-misc/rsync-3.2.3-r1::gentoo_prefix USE="iconv ipv6 ssl (-acl) -examples -libressl -lz4 -stunnel -system-zlib -xattr -xxhash -zstd" [nomerge ] dev-libs/openssl-1.1.1g:0/1.1::gentoo_prefix USE="asm zlib -bindist -rfc3779 -sctp -sslv3 -static-libs -test -tls-heartbeat -vanilla" [nomerge ] app-misc/ca-certificates-20200601.3.59::gentoo_prefix USE="-cacert" [ebuild N ] sys-apps/debianutils-4.11.2::gentoo_prefix USE="(-installkernel) -static" 155 KiB [ebuild N ] app-misc/ca-certificates-20200601.3.59::gentoo_prefix USE="-cacert" 80457 KiB [ebuild N ] net-misc/rsync-3.2.3-r1::gentoo_prefix USE="iconv ipv6 ssl (-acl) -examples -libressl -lz4 -stunnel -system-zlib -xattr -xxhash -zstd" 1045 KiB [ebuild N ] dev-libs/openssl-1.1.1g:0/1.1::gentoo_prefix USE="asm zlib -bindist -rfc3779 -sctp -sslv3 -static-libs -test -tls-heartbeat -vanilla" 9572 KiB Total: 25 packages (25 new), Size of downloads: 160953 KiB * Error: circular dependencies: (virtual/libcrypt-1-r1:0/1::gentoo_prefix, ebuild scheduled for merge) depends on (sys-libs/glibc-2.32-r3:2.2/2.2::gentoo_prefix, ebuild scheduled for merge) (runtime) (dev-lang/python-3.7.8-r2:3.7/3.7m::gentoo_prefix, ebuild scheduled for merge) (buildtime) (virtual/libcrypt-1-r1:0/1::gentoo_prefix, ebuild scheduled for merge) (buildtime_slot_op) It might be possible to break this cycle by applying the following change: - virtual/libcrypt-1-r1 (Change USE: -elibc_glibc)
you want to add sys-libs/glibc-2.32-r2 to your package.provided :(. virtual/libcrypt isn't really Prefix-proof.
That seems to work, it's emerging 40 packages now. I'll keep you updated.
(In reply to Fabian Groffen from comment #16) > you want to add sys-libs/glibc-2.32-r2 to your package.provided :(. > virtual/libcrypt isn't really Prefix-proof. Apparently this isn't the first time either, bleh. bug 740446, bug 733722.
It worked!! It failed at some point because it synced the repo, and discarded my changed in the profile. After I restored them, it continued. There was one more issue with librtas installing files outside the prefix. I changed this: emake DESTDIR="${D}" install docdir=/usr/share/doc/${PF} to emake DESTDIR="${D}" install and that worked. I just tried now with: emake install and that also seems to work fine. Other than that, there were no more issues and the installation completed. So, summarizing, I had to do the following, if my notes are correct: - copy ppc64 in $EPREFIX/var/db/repos/gentoo/profiles/prefix/linux to ppc64le - change the CHOST in make.defaults to CHOST="powerpc64le-pc-linux-gnu" - make a package.provided containing: sys-kernel/linux-headers-5.9 sys-libs/glibc-2.32-r2 - added the following to the the bootstrap script (around line 403): powerpc64le-unknown-linux-gnu) profile=${profile_linux/ARCH/ppc64le} ;; Could this somehow be included in the repository? And if so, do you need any more information? Thanks again for all the help!
Oh, forgot to include that the bootstrap script had to be run with: PREFIX_DISABLE_RAP=yes
And, as mentioned before, the librtas ebuild needed a ~ppc64-linux keyword. I think that's really it :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=432c140439ba4f63e7c4126919c27db08d05e737 commit 432c140439ba4f63e7c4126919c27db08d05e737 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-01 19:08:25 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-01 19:10:34 +0000 profiles/prefix/linux: add ppc64le profile Bug: https://bugs.gentoo.org/755551 Signed-off-by: Fabian Groffen <grobian@gentoo.org> profiles/prefix/linux/ppc64le/eapi | 1 + profiles/prefix/linux/ppc64le/make.defaults | 12 ++++++++++++ profiles/prefix/linux/ppc64le/packages | 7 +++++++ profiles/prefix/linux/ppc64le/parent | 2 ++ 4 files changed, 22 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=63a395a7bd086259dcd12edd344e528b54233327 commit 63a395a7bd086259dcd12edd344e528b54233327 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-01 19:18:45 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-01 19:19:37 +0000 scripts/bootstrap-prefix: add powerpc64le profile setup Bug: https://bugs.gentoo.org/755551 Signed-off-by: Fabian Groffen <grobian@gentoo.org> scripts/bootstrap-prefix.sh | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
We need a snapshot bump before this works, but we also need to sort out the package.mask entries in the tree itself.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=630e66192f8b93b459a52d2bbc846bc15c0b9eab commit 630e66192f8b93b459a52d2bbc846bc15c0b9eab Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-09 19:52:51 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-09 19:52:51 +0000 sys-libs/librtas-2.0.2-r1: marked ~ppc64-linux Bug: https://bugs.gentoo.org/755551 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-libs/librtas/librtas-2.0.2-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
OK, I've just pushed a CentOS bootstrap up to emerge -e system phase. I've killed some mis-deps on linux-headers, so hopefully that helps here too. I've just keyworded librtas, are there more keywords missing for this arch?
Nice, thanks. I'm now running the bootstrap again and will let you know how that goes.
So far, everything is going smoothly (now building gcc in the 'emerge system' step), except for one issue with librtas, which is installing doc files outside the prefix. I forgot to include that in the summary of all issues in of my last comments here, but this is the line of the ebuild file that's causing the issue: emake DESTDIR="${D}" install docdir=/usr/share/doc/${PF} Just doing the following seems to work fine for me (which probably sets docdir to a default/correct path?) : emake install
odd I didn't catch that one yesterday. The real fix should be: emake DESTDIR="${D}" install docdir=${EPREFIX}/usr/share/doc/${PF} I'll commit that to the ebuild. Seems most issues are fixed in any case, so that's good news!
(In reply to Fabian Groffen from comment #29) > odd I didn't catch that one yesterday. Duh. I don't have a powerpc machine to test this on. At least a power4 isn't sufficient I suppose.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8b99dc23f3ee41ca44697f4bd0b0db2630d8e5b commit f8b99dc23f3ee41ca44697f4bd0b0db2630d8e5b Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-10 12:30:09 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-10 12:30:09 +0000 sys-libs/librtas-2.0.2-r1: fix install for Prefix Bug: https://bugs.gentoo.org/755551 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-libs/librtas/librtas-2.0.2-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I ran into the same thing again after it synced the repo and tried to install the same package again, but fixed it again (using your suggestion) and then the installation completed without issues. This was on a POWER8 machine by the way, I'm now trying it on a POWER9 as well and will let you know how that goes (though I don't expect any differences).
(In reply to Fabian Groffen from comment #30) > (In reply to Fabian Groffen from comment #29) > > odd I didn't catch that one yesterday. > > Duh. I don't have a powerpc machine to test this on. At least a power4 > isn't sufficient I suppose. FWIW, Fabian, we can give you access to the Gentoo ppc64 stuff, but it's POWER8 IIRC.
I was thinking, if Bob has resources to run bootstrap once every week or so to verify all is still well, I could set up access to upload the results to https://bootstrap.prefix.bitzolder.nl/results/ such that we can track whether or not the port is doing OK or not. But with a distro like CentOS, these days a different CPU really isn't much of a challenge, so most of it will be covered by x86_64 bootstraps too.
I think I can do that. We are doing this ppc64 build for our EESSI project (which I think you've heard about already? https://www.eessi-hpc.org/) and we got Openstack access for our project to: https://osuosl.org/services/powerdev/ So I can probably run the script every week on an instance there.
@Fabian: the installation on a POWER9 instance also succeeded! :-) @Benda: thanks, that link could be useful, as I was about to ask if there were perhaps suggestions to fixing the issue that I have with RAP enabled. I wasn't really aware what PREFIX_DISABLE_RAP actually does, but from what I understand now it means that it will use the host's libc instead of building its own version? We want to use this Prefix layer in our project to have a common ground for scientific software installations, so that you can use those on basically any Linux distro (using this particular architecture). If we don't ship libc, we will probably run into issues on distros with an older libc. I will try the suggestions from that post and see if that solves the issue. Since it seems to be picking up the wrong glibc at some point, I hope that last part of the message solves this issue...
Hi Bob, thank you for bringing this up! Back in 2017, François Bissey had developed a standalone (a.k.a. RAP) versioned ppc64 profile[1]. It worked in an HPC environment, too. But due to lack of maintenance, the profiles were dropped during 13.0 -> 17.0 migration (See bug #673278). I am glad to see EESSI is going to provide ppc64 Gentoo Prefix to the community. It's nice that prefix-rpath works now on CentOS 8, thanks to Fabian. But if you need compatibility with CentOS 6 or 7, or even 5, prefix-standalone will adapt more smoothly on very old linux kernel and glibc versions. I am ready to help if you would like to push forward the prefix-standalone ppc64. One potential setback is that there is no ppc64 superpower in my research group. I might not have enough energy and commitment to maintain it long term. But I am happy to do proxy-maintaining. Yours, Benda 1. https://archives.gentoo.org/gentoo-alt/message/fe49595527e3c7918844096bf2ae289c
Right. Prefix (non-RAP) just ensures most of the packages and dependencies are in order now. We should aim at fixing RAP, as it in general is the better choice, unless in your development you really rely on the host system a lot. This is not your aim, so now we're a bit in a better position package/deps wise, let's revisit the RAP bootstrap problems again. Benda is the real guy behind RAP though, so I hope he can take it from here :)
Hi Benda, Thanks for your offer to help! I had a look at the patch described in that message, but I think it's already implemented here (?): https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/features/prefix/standalone/profile.bashrc#n9 What I've tried so far is the following: - Run the bootstrap script, it will fail when setting the profile, because there's no prefix/kernel-3.2+ folder here: https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/default/linux/ppc64le/17.0 - I've copied that folder from arm64, since it doesn't really look like there is anything specific to that arch in those files. - Then resumed the bootstrap script, which will complete stage 1. - During stage2 it will fail while building sys-apps/baselayout-prefix, because of a missing keyword. This can be easily fixed by adding ~ppc64. - Stage 2 then completes successfully. - In stage 3, binutils will fail, because there's some kind of circular symlink lib64/ld64.so.1 -> ../lib64/ld64.so.1. See my original post for more details, but I could fix that by changing the glibc ebuild (before glibc gets installed) and setting the correct ld.so filename for ppc64 little endian to: /lib64/ld64.so.2 (instead of .1) I think this is a bug in the current glibc ebuild? Also see: https://sourceware.org/glibc/wiki/ABIList#powerpc After fixing this, binutils finds the correct file: * LDFLAGS: -L/home/centos/gentoorap/usr/lib64 -Wl,--dynamic-linker=/home/centos/gentoorap/lib64/ld64.so.2 (otherwise it will report ld64.so.1 here) I also saw some similar lines in toolchain-glibc.eclass. I don't know if/where these are used, but I changed it there as well. - With these fixes, binutils, gcc, and some more get installed, but the installation of ncurses fails with lots of these: gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) Appending rules for normal model (ncurses: ticlib+termlib+ext_tinfo) gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) I'm not sure how to proceed here. It looks like it's picking up the glibc/linker from my host, e.g. I see this on the gawk of my Prefix: $ readelf -l ./gawk | grep lib [Requesting program interpreter: /lib64/ld64.so.2] On other installations that we've done on aarch64 and x86_64, that command will show the correct linker, i.e. the one from the Prefix installation. I hope you have some suggestions... :-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=60b361ff1c25f6bbe3d533ca4e9bcfc2a56ef2c5 commit 60b361ff1c25f6bbe3d533ca4e9bcfc2a56ef2c5 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2020-12-13 02:45:26 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2020-12-13 03:01:31 +0000 profiles/d/l/ppc64le/17.0/prefix: new ppc64le prefix profiles. Profiles needed to port Gentoo Prefix to ppc64le. Bug: https://bugs.gentoo.org/755551 Suggested-by: Bob Dröge <b.e.droge@rug.nl> Signed-off-by: Benda Xu <heroxbd@gentoo.org> profiles/default/linux/ppc64le/17.0/prefix/kernel-3.2+/eapi | 1 + profiles/default/linux/ppc64le/17.0/prefix/kernel-3.2+/parent | 2 ++ profiles/default/linux/ppc64le/17.0/prefix/parent | 1 + 3 files changed, 4 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=adc7a8a24881ce735592c0bb05b2576d6806b531 commit adc7a8a24881ce735592c0bb05b2576d6806b531 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2020-12-13 02:29:46 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2020-12-13 03:00:56 +0000 sys-apps/baselayout-prefix: keyword ppc64. This is needed to do Prefix bootstrap on ppc64, to support EESSI. Suggested-by: Bob Dröge <b.e.droge@rug.nl> Bug: https://bugs.gentoo.org/755551 Package-Manager: Portage-3.0.5, Repoman-3.0.1 Signed-off-by: Benda Xu <heroxbd@gentoo.org> sys-apps/baselayout-prefix/baselayout-prefix-2.6-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
@ppc64 Team, I am trying to understand the correct filename of the dynamic linker on Gentoo ppc64le. As analyzed by Bob, our glibc ebuild ensures a file or symlink to be at /lib64/ld64.so.1 [1]. However, the glibc ABI defines little-endian ppc64 to have dynamic linker at /lib64/ld64.so.2[2]. Is it by design? What dynamic linker does a Gentoo system featuring profiles/default/linux/ppc64le have? Thanks, Benda 1. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.32-r5.ebuild#n1273 2. https://sourceware.org/glibc/wiki/ABIList#powerpc
Hi Benda, I tried the updated script and it indeed fixes all the stage 1 and 2 issues I ran into before. Here are some more details about the glibc issue that pops up while building binutils: >>> Configuring source in /home/centos/gentoodec14/var/tmp/portage/sys-devel/binutils-2.35.1-r1/work/binutils-2.35.1 ... * strip-flags: CPPFLAGS: changed '-isystem /home/centos/gentoodec14/usr/include' to '' * strip-flags: LDFLAGS: changed '-L/home/centos/gentoodec14/usr/lib64 -Wl,--dynamic-linker=/home/centos/gentoodec14/lib64/ld64.so.1 /home/centos/gentoodec14/lib64/ld64.so.2' to '-L/home/centos/gentoodec14/usr/lib64 -Wl,--dynamic-linker=/home/centos/gentoodec14/lib64/ld64.so.1' * CATEGORY: sys-devel * CBUILD: powerpc64le-unknown-linux-gnu * CHOST: powerpc64le-unknown-linux-gnu * CTARGET: powerpc64le-unknown-linux-gnu * CFLAGS: -O2 -pipe -O2 -pipe * LDFLAGS: -L/home/centos/gentoodec14/usr/lib64 -Wl,--dynamic-linker=/home/centos/gentoodec14/lib64/ld64.so.1 ./configure --enable-plugins --enable-gold --disable-nls --with-system-zlib --build=powerpc64le-unknown-linux-gnu --enable-secureplt --enable-default-hash-style=gnu --prefix=/home/centos/gentoodec14/usr --host=powerpc64le-unknown-linux-gnu --target=powerpc64le-unknown-linux-gnu --datadir=/home/centos/gentoodec14/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.35.1 --datarootdir=/home/centos/gentoodec14/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.35.1 --infodir=/home/centos/gentoodec14/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.35.1/info --mandir=/home/centos/gentoodec14/usr/share/binutils-data/powerpc64le-unknown-linux-gnu/2.35.1/man --bindir=/home/centos/gentoodec14/usr/powerpc64le-unknown-linux-gnu/binutils-bin/2.35.1 --libdir=/home/centos/gentoodec14/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.35.1 --libexecdir=/home/centos/gentoodec14/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.35.1 --includedir=/home/centos/gentoodec14/usr/lib64/binutils/powerpc64le-unknown-linux-gnu/2.35.1/include --enable-obsolete --enable-shared --enable-threads --enable-relro --enable-install-libiberty --enable-textrel-check=warning --disable-werror --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 2.35.1 p2 --disable-static --disable-gdb --disable-libdecnumber --disable-readline --disable-sim --without-stage1-ldflags --with-extra-soversion-suffix=gentoo-sys-devel-binutils-st checking build system type... powerpc64le-unknown-linux-gnu checking host system type... powerpc64le-unknown-linux-gnu checking target system type... powerpc64le-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /home/centos/gentoodec14/tmp/usr/bin/sed checking for gawk... gawk checking for powerpc64le-unknown-linux-gnu-gcc... powerpc64le-unknown-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/home/centos/gentoodec14/var/tmp/portage/sys-devel/binutils-2.35.1-r1/work/build': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details * ERROR: sys-devel/binutils-2.35.1-r1::gentoo failed (configure phase): * (no error message) In my lib64 directory I see the following: $ ls -l lib64 total 4812 -rwxr-xr-x. 1 centos centos 354056 14 dec 20:43 ld-2.32.so lrwxrwxrwx. 1 centos centos 18 14 dec 20:43 ld64.so.1 -> ../lib64/ld64.so.1 lrwxrwxrwx. 1 centos centos 10 14 dec 20:43 ld64.so.2 -> ld-2.32.so There's some kind of circular symlink ld64.so.1 now, besides the (correct?) ld64.so.2 symlink. The error in the config.log of binutils is also related to this: Too many levels of symbolic links Hope this helps in identifying the issue. If it helps, I could give you / someone from the pcc64 team temporary access to a POWER9 instance?
I was just wondering if anyone has any suggestions on how to proceed? I'd be happy to spend some more time on it myself, but I don't really have a clue what I should/can try. I can solve the weird/circular symlink by patching the glibc ebuild file, but then I run into the issues described in comment #39.
not sure, but I think there is a slight problem here in how the ppcle profile sets up the system. Looking at glibc ebuild (line 1300 or so) the ldso_abi_list is used to setup a symlink. I fear SYMLINK_LIB might be set or not, but what accounts here, is that dosym ../$(get_abi_LIBDIR ${ldso_abi})/${ldso_name##*/} ${ldso_name} is probably the producer of your invalid symlink. It is too much guessing at that point for me, but I think it would be a start to have the install image of glibc (ebuild glibc... install perhaps?) and see what it trying to produce there. It may be a profile problem, and SYMLINK_LIB may be the culprit.
(In reply to Fabian Groffen from comment #44) > not sure, but I think there is a slight problem here in how the ppcle > profile sets up the system. > > Looking at glibc ebuild (line 1300 or so) the ldso_abi_list is used to setup > a symlink. I fear SYMLINK_LIB might be set or not, but what accounts here, > is that > > dosym ../$(get_abi_LIBDIR ${ldso_abi})/${ldso_name##*/} ${ldso_name} > > is probably the producer of your invalid symlink. > > It is too much guessing at that point for me, but I think it would be a > start to have the install image of glibc (ebuild glibc... install perhaps?) > and see what it trying to produce there. It may be a profile problem, and > SYMLINK_LIB may be the culprit. ppc64 team confirmed that SYMLINK_LIB is the culprit.
Okay, thanks! So that means I should retry it with SYMLINK_LIB=no in the profile?
Created attachment 684058 [details, diff] Patch to fix prefixifying of dynamic linker for ppc64 Forgive if this was already established above, I didn't read all the comments too closely. I landed here while about to submit a patch to fix this issue, wasn't aware it was already reported while debugging. In any case, here the patch that worked for me, and an explanation in the commit message in the patch file.
Hi Alexei, That looks like the exact same issue I was running into, great that you have a fix! I'm testing it now, and it already passed the point where it failed before (stage 3, ncurses), so it looks very promising. Thank you very much! Did you also have the issue with the broken ld symlink, by the way? See comment #42 for some details: https://bugs.gentoo.org/755551#c42 I can solve it by either just removing the symlink and resuming, or by editing the glibc ebuild as described in #39: https://bugs.gentoo.org/755551#c39
It worked! :-) Still had to fix (remove) the symlink somewhere halfway the installation, but other than that the bootstrap completed without issues. Thanks again everyone!
(In reply to Bob Dröge from comment #49) > It worked! :-) > Still had to fix (remove) the symlink somewhere halfway the installation, > but other than that the bootstrap completed without issues. > > Thanks again everyone! Marvelous! We have another piece of good news at the Easybuild User Meeting!
(In reply to Benda Xu from comment #50) > (In reply to Bob Dröge from comment #49) > > It worked! :-) > > Still had to fix (remove) the symlink somewhere halfway the installation, > > but other than that the bootstrap completed without issues. > > > > Thanks again everyone! > > Marvelous! We have another piece of good news at the Easybuild User Meeting! @benda: did you commit the bit from Alexei?
Created attachment 684145 [details, diff] Patch to fix prefixifying of dynamic linker for ppc64 (updated commit msg) Updated commit message to mention this bug number. Bob, yes, I have the same problem with circular symlink for ld64.so.1. But, I tried patching glibc ebuild, but it did not help, bad symlink still created. So, that issue is still outstanding. The workaround I'm using is to manually rm the link and rerun bootstrap-prefix.sh
Created attachment 684148 [details, diff] Patch to glibc ebuild to set dynamic linker for ppc64 LE and BE This is the patch to glibc ebuild that I tried that does NOT eliminate the broken circular symlink (/lib64/ld64.so.1). But, this patch seems to make sense regardless of this bug. I did not touch ebuilds for versions that did not have the relevant code for ppc64. Question: which repository does portage-YYYYMMDD.tar.xz snapshot come from? I see that gentoo-YYYYMMDD.tar.xz comes from gentoo.git, but the other one has totally different ebuild versions for glibc for example... I can't track its source down. To be clear, to test the above patch, I added a patch command to boostrap-prefix.sh after it unpacked portage-YYYYMMDD.tar.xz, so that test is ok, I just can't figure out where should patches to stuff in this portage be committed to, if it's not gentoo.git.
Weird that this patch didn't solve the symlink issue for you. I've tried that same solution a while ago too, and it worked fine. If I remember correctly, the bootstrap does a sync at some point and then overwrote my modified glibc ebuild file. Could it be that something similar happened to you?
One other thing: I also recently noticed that the file eclass/toolchain-glibc.eclass in the Gentoo overlay has the same piece of code as in the glibc ebuild file. I'm not sure if that's still being used (as it worked fine for me when I only changed the ebuild file itself), but perhaps this should also be patched?
Created attachment 684207 [details, diff] Patch to glibc ebulid to fix dynamic linker path for ppc64 LE (rebased) Rebased patch. The prior patch was on top of out-of-date working copy which is the cause of the patch not helping (Bob, yes there is an tree update step, but it happens after the failure; my problem was that the patch stayed applied but it patched old version of the glibc due to my not paying attention). The prefix bootstraps completely with this new patch. To summarize, the current two attachments resolve this bug.
Hi all, I was wondering what is needed to get Alexei's patch merged? We've been using this for a while in a ppc64le software stack in the EESSI project, and it seems to work really well.
(In reply to Bob Dröge from comment #57) > Hi all, > > I was wondering what is needed to get Alexei's patch merged? We've been > using this for a while in a ppc64le software stack in the EESSI project, and > it seems to work really well. Yes, this is on my top priority list. Thanks Alexei and Bob! Benda
@toolchain Could you please review/apply the glibc patch, please?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07433fc7688d7b49c29440b995719210bb441d22 commit 07433fc7688d7b49c29440b995719210bb441d22 Author: Alexei Colin <acolin@isi.edu> AuthorDate: 2021-01-22 05:01:50 +0000 Commit: Guilherme Amadio <amadio@gentoo.org> CommitDate: 2021-06-07 15:22:22 +0000 profiles: prefixify dynamic linker for ppc64 Bug: https://bugs.gentoo.org/755551 The issue: prefix stage3 fails because the binaries built by the stage3 GCC toolchain fail to run, because they refer to the host's dynamic linker: $ which gawk /myprefix/usr/bin/gawk $ gawk --version gawk: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gawk) $ readelf -l $(which gawk) | grep -i 'program [Requesting program interpreter: /lib64/ld64.so.2] The cause is that the toolchain doesn't insert a prefixified path into the binary because the default -dynamic-linker is not prefixified: $ which powerpc64le-unknown-linux-gnu-gcc /myprefix/usr/bin/powerpc64le-unknown-linux-gnu-gcc $ echo 'int main() { return 0; }' > test.c $ powerpc64le-unknown-linux-gnu-gcc -v -o test test.c COLLECT_GCC_OPTIONS='-v' '-o' 'testx' /myprefix/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/10.2.0/collect2 --eh-frame-hdr -V -m elf64lppc -dynamic-linker /libb64/ld64.so.2 ... The root cause: Prefixifying is done by patching the GCC source code with a sed expression in profile.bashrc. The pattern in that sed expression doesn't match the source file for ppc64 (aka. rs6000). The ppc64 file differs from the rest in that it has a macro for the prefix. Notes on fix: I opted to special-case another sed expression to set that unique DYNAMIC_LINKER_PREFIX macro rather than attempt to make a single sed expression that would modify the *_DYNAMIC_LINKER macros in ppc64. Rationale is that if someone happens to look at the patched source file, it would make more sense if the DYNAMIC_LINKER_PREFIX is set to our prefix, instead of if that macro is set to empty but the *_DYNAMIC_LINKER macros have effectively two prefixes, one hardcoded added by sed, one from the DYNAMIC_LINKER_PREFIX macro. Signed-off-by: Alexei Colin <ac@alexeicolin.com> Signed-off-by: Guilherme Amadio <amadio@gentoo.org> profiles/features/prefix/standalone/profile.bashrc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59ad8840f2ded712964ba82afb1833946bd45a69 commit 59ad8840f2ded712964ba82afb1833946bd45a69 Author: Alexei Colin <ac@alexeicolin.com> AuthorDate: 2021-01-22 20:23:39 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-06-07 22:16:46 +0000 sys-libs/glibc: fix ld.so symlink for ppc64 LE From https://sourceware.org/glibc/wiki/ABIList#powerpc glibc supports two dynamic linker paths: - 64-bit ELFv1 BE: /lib64/ld64.so.1 (ELFv2 BE is not supported) - 64-bit ELFv2 LE: /lib64/ld64.so.2 (ELFv1 LE is not supported) Bug: https://bugs.gentoo.org/755551 Signed-off-by: Alexei Colin <ac@alexeicolin.com> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain-glibc.eclass | 5 ++++- sys-libs/glibc/glibc-2.33.ebuild | 5 ++++- sys-libs/glibc/glibc-9999.ebuild | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-)
Yeah, we kept installing incorrect extra symlink on ppc64le for a while. So far I applied the change only to ~arch glibc. If it works out fine we can sync if to older ebuilds.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f03fe55907dbce2d0fcb65449146e01e4fe7a30 commit 0f03fe55907dbce2d0fcb65449146e01e4fe7a30 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-06-08 07:17:34 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-06-08 07:19:28 +0000 sys-libs/glibc: backport ld.so symlink fix for ppc64 LE From https://sourceware.org/glibc/wiki/ABIList#powerpc glibc supports two dynamic linker paths: - 64-bit ELFv1 BE: /lib64/ld64.so.1 (ELFv2 BE is not supported) - 64-bit ELFv2 LE: /lib64/ld64.so.2 (ELFv1 LE is not supported) Bug: https://bugs.gentoo.org/755551 Signed-off-by: Alexei Colin <ac@alexeicolin.com> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.19-r2.ebuild | 5 ++++- sys-libs/glibc/glibc-2.30-r9.ebuild | 5 ++++- sys-libs/glibc/glibc-2.31-r7.ebuild | 5 ++++- sys-libs/glibc/glibc-2.32-r6.ebuild | 5 ++++- sys-libs/glibc/glibc-2.32-r7.ebuild | 5 ++++- sys-libs/glibc/glibc-2.32-r8.ebuild | 5 ++++- 6 files changed, 24 insertions(+), 6 deletions(-)
I've just tested the patches by doing a bootstrap on ppc64le: everything works like a charm. Thanks again to everyone who helped to fix this! :-)
Thanks to all who bring this into reality. Yay!
