Created attachment 510242 [details] Example of package failing to install with 17.0 profile: libtool Hi, Following news from 2017-11-30 - New 17.0 profiles in the Gentoo repository, I've switched from default/linux/ia64/13.0/desktop/gnome/systemd to default/linux/ia64/17.0/desktop/gnome/systemd profile, rebuilt gcc, binutils and glibc. This quickly left my system in a completely broken state. emerge -e @world led to all packages failing to install. Well, there's no such message per se, but the last thing I was able to read for each package was "Installing package..." then build.log output of each package is displayed on screen. Please find attach build.log for failed emerge of libtool as an example. There's nothing obvious in it, but libtool failed to install properly. Since all packages were failing to install, /var/tmp/portage quickly ran out of space. I wasn't even able to su root in another terminal to try to recover things further. I was getting the following error: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at /var/tmp/portage/sys-apps/systemd-233-r6/work/systemd-233/src/basic/time-util.c:66, function now(). Aborting. Aborted Since 13.0 profiles will be deleted within 6 months, I'm setting this BR to BLOCKER as you won't be able to do anything with your ia64 box. Even worse, you'll have hard time to recover from a Gentoo ia64 boot CD: EFI can't see anything bootable (at least with current install-ia64-minimal-20170926.iso). Fortunately, I still have an old install-ia64-minimal-20161111.iso image with working elilo.efi (see bug #575300 for details). So please be careful: DON'T SWITCH TO 17.0 PROFILE ON IA64 YET! You've been warned! You'll be left with a completely broken and unbootable system, without any possibility to recover from there as current Gentoo ia64 boot CD is broken too. Émeric
emerge --info output: Portage 2.3.13 (python 3.5.4-final-0, default/linux/ia64/13.0/desktop/gnome/systemd, gcc-6.4.0, glibc-2.25-r9, 4.12.12-gentoo ia64) ================================================================= System uname: Linux-4.12.12-gentoo-ia64-Madison-with-gentoo-2.4.1 KiB Mem: 24978192 total, 21201344 free KiB Swap: 524272 total, 524272 free Timestamp of repository gentoo: Sat, 09 Dec 2017 19:45:01 +0000 Head commit of repository gentoo: 07201fba03ac285e39726ee2171222f09c629a64 sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.29.1 p3) 2.29.1 app-shells/bash: 4.3_p48-r1::gentoo dev-lang/perl: 5.24.3::gentoo dev-lang/python: 2.7.14-r1::gentoo, 3.5.4-r1::gentoo dev-util/cmake: 3.8.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.11::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.15.1-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo sys-devel/gcc: 4.5.4::gentoo, 6.4.0::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.25-r9::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.fr.gentoo.org/gentoo-portage priority: -1000 sync-rsync-extra-opts: localrepo location: /usr/local/portage masters: gentoo ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/chromium/policies/managed/chrome-gnome-shell.json /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/opt/chrome/policies/managed/chrome-gnome-shell.json /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_FR.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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="/var/tmp" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support readline sdl session spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ALSA_CARDS="fm801" 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="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="fr" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr_FR" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22" USERLAND="GNU" VIDEO_CARDS="fbdev radeon" 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, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
eselect profile list output: Available profile symlink targets: [1] default/linux/ia64/13.0 [2] default/linux/ia64/13.0/desktop [3] default/linux/ia64/13.0/desktop/gnome [4] default/linux/ia64/13.0/desktop/gnome/systemd * [5] default/linux/ia64/13.0/developer [6] default/linux/ia64/17.0 [7] default/linux/ia64/17.0/desktop [8] default/linux/ia64/17.0/desktop/gnome [9] default/linux/ia64/17.0/desktop/gnome/systemd [10] default/linux/ia64/17.0/developer [11] hardened/linux/ia64 I had to revert to default/linux/ia64/13.0/desktop/gnome/systemd to be able to recover my system and rebuild everything with emerge -e @world
The build log does not contain errors. I guess portage itself errors out? Can you try to build 'USE=pie gcc' in the chroot and see if it survives 17.0 profile at least for basic functionality? For that you would need to un-force USE=pic on gcc as: /etc/portage/profile/package.use.force: sys-devel/gcc -pie and then build USE=-pie gcc.
(In reply to Sergei Trofimovich from comment #3) > Can you try to build 'USE=pie gcc' in the chroot and see if it survives > 17.0 profile at least for basic functionality? Correction: Can you try to build 'USE=-pie gcc' in the chroot and see if it survives 17.0 profile at least for basic functionality?
(In reply to Sergei Trofimovich from comment #3) > The build log does not contain errors. I guess portage itself errors out? That's part of the problem: passed gcc, binutils and glibc, all packages are failing to install without any obvious error logged into their respective build.log files. I don't think if portage itself errors out. If it was failing, I guess that emerge -e @world would exit at the first failure?
(In reply to Sergei Trofimovich from comment #4) > > Correction: > > Can you try to build 'USE=-pie gcc' in the chroot and see if it survives > 17.0 profile at least for basic functionality? Forcing -pie for =sys-devel/gcc:6.4.0 makes libtool build successfully, in addition to gcc, binutils and glibc. So I think that we can assume that pie USE flag is indeed the culprit as libtool was failing to install with PIE-enabled gcc, as reported in my initial comment. I didn't rebuilt @world yet. So just let me know if you want me to try anything else before.
Tried 17.0 profile in a chroot today. Seems to be caused by ldconfig ('emerge --debug -1 libtool' output): >>> Regenerating /etc/ld.so.cache... >>> Failed to install sys-devel/libtool-2.4.6-r3, Log file: >>> '/var/tmp/portage/sys-devel/libtool-2.4.6-r3/temp/build.log' Which is a static binary. I'll try patches from https://bugs.gentoo.org/641474 locally to check if the problem goes away. Patches fix static+default-pie case.
(In reply to Sergei Trofimovich from comment #7) > Tried 17.0 profile in a chroot today. Seems to be caused by ldconfig > ('emerge --debug -1 libtool' output): > > >>> Regenerating /etc/ld.so.cache... > >>> Failed to install sys-devel/libtool-2.4.6-r3, Log file: > >>> '/var/tmp/portage/sys-devel/libtool-2.4.6-r3/temp/build.log' > > Which is a static binary. I'll try patches from > https://bugs.gentoo.org/641474 locally to check if the problem goes away. > Patches fix static+default-pie case. Ran gcc patches on guppy overnight. Did not help. Digging where the error comes from.
(In reply to Sergei Trofimovich from comment #8) > (In reply to Sergei Trofimovich from comment #7) > > Tried 17.0 profile in a chroot today. Seems to be caused by ldconfig > > ('emerge --debug -1 libtool' output): > > > > >>> Regenerating /etc/ld.so.cache... > > >>> Failed to install sys-devel/libtool-2.4.6-r3, Log file: > > >>> '/var/tmp/portage/sys-devel/libtool-2.4.6-r3/temp/build.log' > > > > Which is a static binary. I'll try patches from > > https://bugs.gentoo.org/641474 locally to check if the problem goes away. > > Patches fix static+default-pie case. > > Ran gcc patches on guppy overnight. Did not help. Digging where the error > comes from. Looks like glibc fails to perform lazy relocation preprocessing (supposedly in python and other executables). I've seen SIGSEGVs in 'git' as well. The workaround is to add LD_BIND_NOW=1 to force eager binding: LD_BIND_NOW=1 emerge -v1 libtool
glibc's master fails a bunch of tests. I think this is relevant: FAIL: rt/tst-clock $ cat rt/tst-clock.out Didn't expect signal from child: got `Segmentation fault'
$ cat a.c #include <time.h> #include <stdio.h> int main() { struct timespec t; int r = clock_getres(CLOCK_REALTIME, &t); printf ("r=%i; tv_sec=%llu, tv_nsec=%llu\n", r, (unsigned long long)t.tv_sec, (unsigned long long)t.tv_nsec); } $ gcc -Wall a.c -o a $ ./a r=0; tv_sec=0, tv_nsec=4000000 $ gcc -Wall a.c -o a -lrt $ ./a SIGSEGV (core dumped) $ LD_BIND_NOW=1 ./a r=339656; tv_sec=0, tv_nsec=0
(In reply to Sergei Trofimovich from comment #11) > $ cat a.c > #include <time.h> > #include <stdio.h> > > int main() { > struct timespec t; > int r = clock_getres(CLOCK_REALTIME, &t); > printf ("r=%i; tv_sec=%llu, tv_nsec=%llu\n", r, (unsigned long > long)t.tv_sec, (unsigned long long)t.tv_nsec); > } > > $ gcc -Wall a.c -o a > $ ./a > r=0; tv_sec=0, tv_nsec=4000000 > > $ gcc -Wall a.c -o a -lrt > $ ./a > SIGSEGV (core dumped) > > $ LD_BIND_NOW=1 ./a > r=339656; tv_sec=0, tv_nsec=0 I don't know how it relates, but when I was looking for the reason why I was getting the following systemd error when trying to su root Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at /var/tmp/portage/sys-apps/systemd-233-r6/work/systemd-233/src/basic/time-util.c:66, function now(). I was quickly redirected to [1]. I'm not familiar with the details there, but there was talk about CLOCK_REALTIME_ALARM not supported on all architectures. If I understand it correctly, CLOCK_REALTIME_ALARM should simply map to CLOCK_REALTIME on "exotic architectures". Since I can read CLOCK_REALTIME in your test program, by "chance" is glibc hitting a related issue on ia64? [1] https://github.com/systemd/systemd/issues/2597
(In reply to Émeric Maschino from comment #12) > (In reply to Sergei Trofimovich from comment #11) > I don't know how it relates, but when I was looking for the reason why I was > getting the following systemd error when trying to su root Should be not directly related.
librt.so provides a bunch of weak symbols as IFUNCs: guppy ~/glibc-ia64 # LANG=C readelf -a /lib/librt.so.1 | fgrep IFUNC 82: 0000000000009800 32 IFUNC GLOBAL DEFAULT 12 clock_getres@@GLIBC_2.2 92: 0000000000009880 32 IFUNC GLOBAL DEFAULT 12 clock_settime@@GLIBC_2.2 118: 00000000000098c0 32 IFUNC GLOBAL DEFAULT 12 clock_getcpuclockid@@GLIBC_2.2 123: 0000000000009900 32 IFUNC GLOBAL DEFAULT 12 clock_nanosleep@@GLIBC_2.2 126: 0000000000009840 32 IFUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.2 Those used to be GLOBALs. I wonder if it's actually caused by newer binutils to support IFUNC on ia64.
Found the problem: in --default-pie mode glibc mis-detects ia64 support for IFUNC: Relevant log snippet from config.log: configure:3948: checking for assembler and linker STT_GNU_IFUNC support Relocation section '.rela.dyn' at offset 0x1b0 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 0000000102e8 00000000006f R_IA64_REL64LSB 1d0 configure:3979: result: yes It should be an _IRELATIVE relocation to declare ifunc support. This is unrelated relocation. Instread flibc checks for any relocations and gets tricked by unrelated relocation: https://sourceware.org/git/?p=glibc.git;a=blob;f=configure.ac;h=ca1282a6b3f8c5369c133a47f5c8239c3f2d32b5;hb=HEAD#l597
One of the workarounds is to build glibc as: EXTRA_ECONF=libc_cv_ld_gnu_indirect_function=no emerge -v1 glibc until we get a workaround in the tree.
I've seen it before when I was green gentoo: https://bugs.gentoo.org/336792#c26
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac450135f29ef850303589af998373d936955476 commit ac450135f29ef850303589af998373d936955476 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2017-12-20 09:35:00 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2017-12-20 09:52:55 +0000 sys-libs/glibc: enable IFUNC support only on whitelisted ARCHes, bug #641216 We explicitly disable IFUNC support on the following targets: alpha/hppa/ia64/mips/m68k/nios2/riscv/sh to workaround weak IFUNC detection on binutils/glibc side. Otherwise at least on ia64 glibc generates IFUNC entries against compat librt.so.1 symbols (to redirect them back to libc.so.6) but linker does not produce correct relocations. As a result all IFUNC-backed functions don't work. Reported-by: Émeric Maschino Bug: https://sourceware.org/PR22634 Closes: https://bugs.gentoo.org/641216 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain-glibc.eclass | 11 +++++++++++ sys-libs/glibc/glibc-2.26-r3.ebuild | 11 +++++++++++ 2 files changed, 22 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2094540085135ecf4ec79d9cd9bb2df598d8083b commit 2094540085135ecf4ec79d9cd9bb2df598d8083b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2017-12-20 12:37:04 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2017-12-20 12:37:21 +0000 sys-libs/glibc: enable IFUNC support only on whitelisted ARCHes, bug #641216 Apply commit ac450135f29ef850303589af998373d936955476 to -9999 as well. ("sys-libs/glibc: enable IFUNC support only on whitelisted ARCHes, bug #641216") Reported-by: Émeric Maschino Bug: https://sourceware.org/PR22634 Closes: https://bugs.gentoo.org/641216 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-libs/glibc/glibc-9999.ebuild | 11 +++++++++++ 1 file changed, 11 insertions(+)
(In reply to Larry the Git Cow from comment #19) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=2094540085135ecf4ec79d9cd9bb2df598d8083b > > commit 2094540085135ecf4ec79d9cd9bb2df598d8083b > Author: Sergei Trofimovich <slyfox@gentoo.org> > AuthorDate: 2017-12-20 12:37:04 +0000 > Commit: Sergei Trofimovich <slyfox@gentoo.org> > CommitDate: 2017-12-20 12:37:21 +0000 > > sys-libs/glibc: enable IFUNC support only on whitelisted ARCHes, bug > #641216 > > Apply commit ac450135f29ef850303589af998373d936955476 to -9999 as well. > ("sys-libs/glibc: enable IFUNC support only on whitelisted ARCHes, bug > #641216") > > Reported-by: Émeric Maschino > Bug: https://sourceware.org/PR22634 > Closes: https://bugs.gentoo.org/641216 > Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > > sys-libs/glibc/glibc-9999.ebuild | 11 +++++++++++ > 1 file changed, 11 insertions(+) Sergei, just as a double-check: is it now safe to switch to 17.0 profile on ia64? Your patch hasn't been applied upstream (yet), so just wondering if "Gentoo's" glibc is fine. Émeric
(In reply to Émeric Maschino from comment #20) > Sergei, just as a double-check: is it now safe to switch to 17.0 profile on > ia64? Your patch hasn't been applied upstream (yet), so just wondering if > "Gentoo's" glibc is fine. > > Émeric Yes, 17.0 should be safe to use in Gentoo. Note: there is no patch attached to upstream, only a bug report that check is incomplete.
(In reply to Sergei Trofimovich from comment #21) > > Yes, 17.0 should be safe to use in Gentoo. Switch to 17.0 gnome/systemd profile successfully completed on my side. Many thanks, Émeric