After upgrading to binutils-config-5 gcc stopped working on my uclibc system. Unfortunately a necessary LDPATH line disappeares from 05binutils in env.d and thus gas refuses to work (gas cannot find libbfd). Reproducible: Always Steps to Reproduce: 1. Emerge binutils-config-5 Actual Results: Wrecked build-system Expected Results: A working compiler Readding the necessary path to ld.so.conf does not help since it gets dumped after each package merge. Another odd thing I camre across, the same directory (the one for gcc) gets added 4 times to ld.so.conf.
binutils has rpath tags that point to its internal paths. there's no need for them to be listed in ld.so.conf. looks like a bug in uclibc's ldso.
What is the architecture of the system?
Arch was ~amd64.
(In reply to Sven E. from comment #3) > Arch was ~amd64. I don't doubt there's something wrong with uclibc's ldso, but I can't seem to reproduce it. Can you give me more information about the system. Did you start with one of my stage3's? Did you cross compile?
(In reply to Anthony Basile from comment #4) > (In reply to Sven E. from comment #3) > > Arch was ~amd64. > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > to reproduce it. > > Can you give me more information about the system. Did you start with one > of my stage3's? Did you cross compile? I just hit it on i686 on one of my stages3. So we have an issue probably across all uclibc arches: 0. emerge binutils-config-5-r1; env-update. 1. cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /lib /usr/lib /usr/local/lib /usr/lib/gcc/i686-gentoo-linux-uclibc/4.9.3 /usr/lib/gcc/i686-gentoo-linux-uclibc/4.9.3 /usr/lib/gcc/i686-gentoo-linux-uclibc/4.9.3 /usr/lib/gcc/i686-gentoo-linux-uclibc/4.9.3 /usr/lib/gcc/i686-gentoo-linux-uclibc/4.9.3 Note this line is gone: /usr/i686-gentoo-linux-uclibc/lib 2. # as as: can't load library 'libbfd-2.25.1.so' 3. readelf -d `which as` Dynamic section at offset 0x5fc9c contains 24 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libopcodes-2.25.1.so] 0x00000001 (NEEDED) Shared library: [libbfd-2.25.1.so] 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.0] 0x0000001d (RUNPATH) Library runpath: [/usr/lib/binutils/i686-gentoo-linux-uclibc/2.25.1] 0x0000000c (INIT) 0x3318 0x0000000d (FINI) 0x4a528 0x6ffffef5 (GNU_HASH) 0x168 4. ls /usr/lib/binutils/i686-gentoo-linux-uclibc/2.25.1 include ldscripts libbfd-2.25.1.so libbfd.so libiberty.a libopcodes-2.25.1.so libopcodes.so So, DT_RUNPATH is broken. Right now, mips is in trouble because its a ~arch. The other arches will get the problem when binutils-config-5-r1 goes stable. @vapier this may take a while to fix in uclibc. would it be bad if i masked binutils-config-5 on all uclibc profiles? also i'll look to see if there's some fix in master that i can backport to 0.9.33 branch.
(In reply to Anthony Basile from comment #5) > > @vapier this may take a while to fix in uclibc. would it be bad if i masked > binutils-config-5 on all uclibc profiles? also i'll look to see if there's > some fix in master that i can backport to 0.9.33 branch. I went ahead and masked >sys-devel/binutils-config-4-r2 in profiles/default/linux/uclibc/package.mask until we figure this one out. I also verified that in fact, a catalyst run fails at stage2 for mips precisely because of the above.
(In reply to Anthony Basile from comment #4) > (In reply to Sven E. from comment #3) > > Arch was ~amd64. > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > to reproduce it. > > Can you give me more information about the system. Did you start with one > of my stage3's? Did you cross compile? Just for completeness: After failing to cross-build a base system (got stuck with python and tar) I decided to use a stage3 - I don't know if it was one of yours, I grabbed it from the gentoo site. While I first hit the error in a chrooted env, I later on booted the chroot env directly, just to see if the problem was related to maybe a faulty chroot env setup. The problem persited though.
(In reply to Sven E. from comment #7) > (In reply to Anthony Basile from comment #4) > > (In reply to Sven E. from comment #3) > > > Arch was ~amd64. > > > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > > to reproduce it. > > > > Can you give me more information about the system. Did you start with one > > of my stage3's? Did you cross compile? > > Just for completeness: > > After failing to cross-build a base system (got stuck with python and tar) I > decided to use a stage3 - I don't know if it was one of yours, I grabbed it > from the gentoo site. > > While I first hit the error in a chrooted env, I later on booted the chroot > env directly, just to see if the problem was related to maybe a faulty > chroot env setup. The problem persited though. The ones off the gentoo mirrors are mine. I asked because 1) I'm responsible for those and want them to be bug free and 2) I needed to reproduce the issue, which I now have. Its pretty clear what's wrong: at least on amd64, i686 and mips DT_RUNPATH is broken for uclibc 0.9.33.x. I'm working on isolating the problem in the code now.
(In reply to Anthony Basile from comment #8) > (In reply to Sven E. from comment #7) > > (In reply to Anthony Basile from comment #4) > > > (In reply to Sven E. from comment #3) > > > > Arch was ~amd64. > > > > > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > > > to reproduce it. > > > > > > Can you give me more information about the system. Did you start with one > > > of my stage3's? Did you cross compile? > > > > Just for completeness: > > > > After failing to cross-build a base system (got stuck with python and tar) I > > decided to use a stage3 - I don't know if it was one of yours, I grabbed it > > from the gentoo site. > > > > While I first hit the error in a chrooted env, I later on booted the chroot > > env directly, just to see if the problem was related to maybe a faulty > > chroot env setup. The problem persited though. > > The ones off the gentoo mirrors are mine. I asked because 1) I'm > responsible for those and want them to be bug free and 2) I needed to > reproduce the issue, which I now have. Its pretty clear what's wrong: at > least on amd64, i686 and mips DT_RUNPATH is broken for uclibc 0.9.33.x. I'm > working on isolating the problem in the code now. Could the fix be that easy?: http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2 Or was this patch added already to the current ebuild?
(In reply to Sven E. from comment #9) > (In reply to Anthony Basile from comment #8) > > (In reply to Sven E. from comment #7) > > > (In reply to Anthony Basile from comment #4) > > > > (In reply to Sven E. from comment #3) > > > > > Arch was ~amd64. > > > > > > > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > > > > to reproduce it. > > > > > > > > Can you give me more information about the system. Did you start with one > > > > of my stage3's? Did you cross compile? > > > > > > Just for completeness: > > > > > > After failing to cross-build a base system (got stuck with python and tar) I > > > decided to use a stage3 - I don't know if it was one of yours, I grabbed it > > > from the gentoo site. > > > > > > While I first hit the error in a chrooted env, I later on booted the chroot > > > env directly, just to see if the problem was related to maybe a faulty > > > chroot env setup. The problem persited though. > > > > The ones off the gentoo mirrors are mine. I asked because 1) I'm > > responsible for those and want them to be bug free and 2) I needed to > > reproduce the issue, which I now have. Its pretty clear what's wrong: at > > least on amd64, i686 and mips DT_RUNPATH is broken for uclibc 0.9.33.x. I'm > > working on isolating the problem in the code now. > > Could the fix be that easy?: > http://git.uclibc.org/uClibc/commit/ > ?id=409f14d9b5e47513d5c939120a33965997c8ceb2 > > Or was this patch added already to the current ebuild? That patch is not in there, but that's not what we want. The option is LDSO_RUNPATH which is on for all uclibc stages in the mirrors. I could be missing a subtle point, so maybe we do need executable RUNPATH/RPATH. It is worth testing this patch.
(In reply to Anthony Basile from comment #10) > (In reply to Sven E. from comment #9) > > (In reply to Anthony Basile from comment #8) > > > (In reply to Sven E. from comment #7) > > > > (In reply to Anthony Basile from comment #4) > > > > > (In reply to Sven E. from comment #3) > > > > > > Arch was ~amd64. > > > > > > > > > > I don't doubt there's something wrong with uclibc's ldso, but I can't seem > > > > > to reproduce it. > > > > > > > > > > Can you give me more information about the system. Did you start with one > > > > > of my stage3's? Did you cross compile? > > > > > > > > Just for completeness: > > > > > > > > After failing to cross-build a base system (got stuck with python and tar) I > > > > decided to use a stage3 - I don't know if it was one of yours, I grabbed it > > > > from the gentoo site. > > > > > > > > While I first hit the error in a chrooted env, I later on booted the chroot > > > > env directly, just to see if the problem was related to maybe a faulty > > > > chroot env setup. The problem persited though. > > > > > > The ones off the gentoo mirrors are mine. I asked because 1) I'm > > > responsible for those and want them to be bug free and 2) I needed to > > > reproduce the issue, which I now have. Its pretty clear what's wrong: at > > > least on amd64, i686 and mips DT_RUNPATH is broken for uclibc 0.9.33.x. I'm > > > working on isolating the problem in the code now. > > > > Could the fix be that easy?: > > http://git.uclibc.org/uClibc/commit/ > > ?id=409f14d9b5e47513d5c939120a33965997c8ceb2 > > > > Or was this patch added already to the current ebuild? > > That patch is not in there, but that's not what we want. The option is > LDSO_RUNPATH which is on for all uclibc stages in the mirrors. I could be > missing a subtle point, so maybe we do need executable RUNPATH/RPATH. It is > worth testing this patch. True.... I might be wrong, but this is what might be happening: Looking at the readelf -d ouput, RUNPATH is set and thus libopcodes and libbfd will be searched in RUNPATH for the executeable. But when loading libopcodes (first dep) from RUNPATH, RUNPATH does not get applied to the entries in the NEEDED section of libopcodes. libopcodes does have a needed entry for libbfd, but no RUNPATH and RUNPATH does not get inherited into libopcodes. At least the comment in the commit suggests that processing of RUNPATH should usually be limited to the <current> object. Now the needed dep for libbfd cannot be resolved while processing libopcodes - and the source does not really suggest that resolving the dep can be 'deferred'. The Commit seems to introduce an 'ancestory search' for RUNPATH, instead of only looking at the current dynamic section. Rather everything in _dl_loaded_modules is searched and thus the executeables' RUNPATH gets used to find libbfd. At least that's the theory. Unfortunately I don't have the chroot around anymore to test if the changes from the commit resolve the issue.
BTW: It might be interesting to try using something like chrpath or patchelf to introduce the RUNPATH (from as) into libopcodes.so. I am curious if this changes anything...
(In reply to Sven E. from comment #11) > > libopcodes does have a needed entry for libbfd, but no RUNPATH and RUNPATH > does not get inherited into libopcodes. At least the comment in the commit > suggests that processing of RUNPATH should usually be limited to the > <current> object. > Now the needed dep for libbfd cannot be resolved while processing libopcodes > - and the source does not really suggest that resolving the dep can be > 'deferred'. I tested the patch and it works. Your explanation sounds reasonable, but I didn't turn on debugging to check for sure. Both glibc and musl do treat RUNPATH transitively, though I have mixed feeling about this behaviour because it sounds like an exploit waiting to happen. I'll see about getting upstream to backport the patch to 0.9.33. It doesn't apply cleanly but for minor reasons. Also I'll add it to our patchset for -r16. I am going to change the default to being on rather than off so that a straight upgrade on the distributed stages will "just work". In the mean time binutils-config-5 is masked.
(In reply to Anthony Basile from comment #13) > (In reply to Sven E. from comment #11) > > > > libopcodes does have a needed entry for libbfd, but no RUNPATH and RUNPATH > > does not get inherited into libopcodes. At least the comment in the commit > > suggests that processing of RUNPATH should usually be limited to the > > <current> object. > > Now the needed dep for libbfd cannot be resolved while processing libopcodes > > - and the source does not really suggest that resolving the dep can be > > 'deferred'. > > I tested the patch and it works. Your explanation sounds reasonable, but I > didn't turn on debugging to check for sure. Both glibc and musl do treat > RUNPATH transitively, though I have mixed feeling about this behaviour > because it sounds like an exploit waiting to happen. > > I'll see about getting upstream to backport the patch to 0.9.33. It doesn't > apply cleanly but for minor reasons. Also I'll add it to our patchset for > -r16. I am going to change the default to being on rather than off so that > a straight upgrade on the distributed stages will "just work". > > In the mean time binutils-config-5 is masked. I tried to find an 'authoriative' source giving info on what the right way of processing is. Some sources say, DT_RPATH only applies to the NEEDED entries in the same object/dynamic section. Another source (old ELF specs) says DT_RPATH is a list of library search paths. It further says that ld needs to do a breadth first search, which in turn means, before processing libopcodes ld should already have knowledge of where to find libbfd (even though the question remains if it may be used for libopcodes' deps afterwards). I can see dis/advantages in both approaches though.
I'm seeing this same behavior but I'm not using uclibc - I'm using sys-libs/glibc-2.22-r1. I noticed this issue as it causes https://bugs.gentoo.org/show_bug.cgi?id=561940 Basically, emerge mariadb then see --- /usr/sbin/mysqld: error while loading shared libraries: libbfd-2.25.1.so: cannot open shared object file: No such file or directory --- in /var/log/mysql/mysqld.err Versions of relevant libraries: [ebuild R ] sys-devel/binutils-config-5-r1::gentoo 0 KiB [ebuild R ] sys-devel/binutils-2.25.1-r1::gentoo USE="cxx nls zlib (-multislot) -multitarget -static-libs {-test} -vanilla" 0 KiB [ebuild R ] sys-libs/binutils-libs-2.25.1-r1:0/2.25.1::gentoo USE="nls zlib -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild R ] sys-libs/glibc-2.22-r1:2.2::gentoo USE="gd (multilib) nscd -debug (-hardened) -profile (-selinux) -suid -systemtap -vanilla" 0 KiB # emerge --info Portage 2.2.23 (python 3.4.3-final-0, default/linux/amd64/13.0, gcc-5.2.0, glibc-2.22-r1, 4.2.3-gentoo x86_64) ================================================================= System uname: Linux-4.2.3-gentoo-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9550_@_2.83GHz-with-gentoo-2.2 KiB Mem: 3978724 total, 404780 free KiB Swap: 4030452 total, 3077272 free Timestamp of repository gentoo: Mon, 02 Nov 2015 14:30:01 +0000 sh bash 4.3_p42 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 ccache version 3.2.4 [disabled] app-shells/bash: 4.3_p42::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10::gentoo, 3.4.3::gentoo dev-util/ccache: 3.2.4::gentoo dev-util/cmake: 3.3.2-r1::gentoo dev-util/pkgconfig: 0.29::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.18.3::gentoo sys-apps/sandbox: 2.9::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 5.2.0::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.2::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 x-portage location: /usr/local/portage masters: gentoo priority: 0 kodi-overlay location: /var/lib/layman/kodi-overlay sync-type: laymansync sync-uri: git://github.com/frace/kodi-overlay.git masters: gentoo priority: 50 mv location: /var/lib/layman/mv sync-type: laymansync sync-uri: git://anongit.gentoo.org/user/mv.git masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay sync-type: laymansync sync-uri: git://github.com/anyc/steam-overlay.git masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA Intel-SDP" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.3/conf /var/spool/munin-async/.ssh" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.5" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -flto" MAKEOPTS="-j5" 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" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac aacs acl acpi aiglx alsa amd64 amr amrnb amrwb animation apache2 apng artworkextra asf aspnet2 asyncns authdaemond avahi avi bash-completion bcmath berkdb bitmap-fonts bluetooth bluray bmp bonjour bzip2 cairo caps cdda cddb cdparanoia cdr celt chm clang cli cracklib crypt cryptsetup css curl cxx daap dbus device-mapper dga dhclient dirac divx4linux dlloader dovecot-sasl dpms dri dts dv dvb dvd dvdr dvdread egl enca encode exif faac fam fame fat fbcondecor fbsplash ffmpeg fftw firefox flac fontconfig foomaticdb fortran freetype ftp fuse gaim gd gdbm geoip gif gimpprint glamor gles glib glibc-omitfp glitz glut gphoto2 gsm gstreamer gstreamer10 gtk gtk2 gudev hardenedphp hbci howl howl-compat http2 https hwdb iconv icu idn imagemagick imap imlib innodb ipv6 java java5 jbig joystick jpeg jpeg2k junit kdbus kdehiddenvisibility kvm lapack lcms libfame libkms libnotify librtmp libsamplerate libusb lirc live llvm lm_sensors lzma lzo mad maildir mdadm mdnsresponder-compat mjpeg mmap mms mmx mmxext mng modules motif mozilla mozsvg mp3 mpeg mpeg2 mplayer multilib musepack mysql mythtv ncurses nemesi network networkmanager nls nptl nptlonly ntfs offensive ofx ogg oggvorbis openal openexr opengl openmp openvg opus pam pango pcre pcre16 pcre32 pdf pdflib perl phonon pic pie plymouth png pnp policykit postgres ppd ppds pulseaudio python qt qt3 qt3support qt4 quicktime quvi rar readline resolvconf rtc rtmp samba schroedinger screensaver sctp sdl seccomp session sftp sharedmem shout smp sna sni snmp sox speex spell sqlite sse sse2 ssh ssl steamruntime suspend2 svg systemd theora threads tiff tls transcode truetype truetype-fonts type-fonts udev udisks unicode unzip upnp ups usb uxa v4l2 vaapi vcd vdpau videos vorbis vpx wayland webdav webp webservices wifi win32codecs wmf wv x264 x265 xanim xattr xcb xcomposite xinerama xml xml2 xpm xprint xrandr xv xvfb xvid xvmc zeroconf zip zlib" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="actions alias auth_basic authn_core authz_core cache_disk authn_alias authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dconf deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest proxy proxy_ajp proxy_connect proxy_http proxy_fcgi reqtimeout cgi cgid unixd socache_shmcb http2" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 sse4_1 ssse3" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev joystick keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" LIRC_DEVICES="userspace" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="arm i386 x86_64" QEMU_USER_TARGETS="arm i386 x86_64" RUBY_TARGETS="ruby22" USERLAND="GNU" VIDEO_CARDS="intel" 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" USE_PYTHON="2.7 3.4" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I think it would be wise to open another BUG-Report for this, as your problem is certainly not related to uclibc's ld.so. (In reply to candrews from comment #15) > I'm seeing this same behavior but I'm not using uclibc - I'm using > sys-libs/glibc-2.22-r1. I noticed this issue as it causes > https://bugs.gentoo.org/show_bug.cgi?id=561940 Basically, emerge mariadb > then see > --- > /usr/sbin/mysqld: error while loading shared libraries: libbfd-2.25.1.so: > cannot open shared object file: No such file or directory > ---
(In reply to Sven E. from comment #16) > I think it would be wise to open another BUG-Report for this, as your > problem is certainly not related to uclibc's ld.so. > > (In reply to candrews from comment #15) > > I'm seeing this same behavior but I'm not using uclibc - I'm using > > sys-libs/glibc-2.22-r1. I noticed this issue as it causes > > https://bugs.gentoo.org/show_bug.cgi?id=561940 Basically, emerge mariadb > > then see > > --- > > /usr/sbin/mysqld: error while loading shared libraries: libbfd-2.25.1.so: > > cannot open shared object file: No such file or directory > > --- Yes. Please open another bug report because we have in principle solved this for uclibc. We just need to "move all the pieces in place". I have no idea what's going on with glibc but a similar bug was triggered by the change in binutils-config-5.
(In reply to SpanKY from comment #1) > binutils has rpath tags that point to its internal paths. there's no need > for them to be listed in ld.so.conf. > > looks like a bug in uclibc's ldso. It is. I traced it back to an address problem in the aux vector table and it only happens on 64-bit systems. It explains why revdep-rebuild kept rebuilding sudo and man-db on amd64. So here's a diagnosis of the problem, take sudo as an example. Note that sudo has a RUNPATH defined. But ldso can't use it. amd64-uclibc-hardened-latest ~ # readelf -d /usr/bin/sudo | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/usr/libexec/sudo] amd64-uclibc-hardened-latest ~ # ldd /usr/bin/sudo /usr/bin/sudo: is setuid checking sub-depends for '/lib/libutil.so.0' checking sub-depends for 'not found' checking sub-depends for '/lib/libc.so.0' libutil.so.0 => /lib/libutil.so.0 (0x00000000) libsudo_util.so.0 => not found (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) /lib/ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x00000000) amd64-uclibc-hardened-latest ~ # ls /usr/libexec/sudo/ libsudo_util.la libsudo_util.so libsudo_util.so.0 libsudo_util.so.0.0.0 sudo_noexec.la sudo_noexec.so There are several places in ldso where Elf32 is used rather than ElfW(Addr) in the 0.9.33 branch. If you fix these (and most are fixed in master) then the problem goes away. But backporting these fixes is not so easy because 0.9.33 and master have really really diverged. The main fix is commit cb5af0bed860aac12b87b2044f6f519deded40f9. After emerging uclibc-9999 ldd gives: amd64-uclibc-hardened-latest ~ # ldd /usr/bin/sudo /usr/bin/sudo: is setuid libutil.so.0 => /lib/libutil.so.0 (0x364d91ae000) libsudo_util.so.0 => /usr/libexec/sudo/libsudo_util.so.0 (0x364d8f99000) libc.so.0 => /lib/libc.so.0 (0x364d8d26000) libdl.so.0 => /lib/libdl.so.0 (0x364d8b22000) ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x364d95d6000) Note even the mappings make more sense. Aside: I'm beginning to wonder what to do with uclibc. I may give up trying to backport, put uclibc-ng in the tree and start using that. *sigh*
(In reply to Anthony Basile from comment #18) > (In reply to SpanKY from comment #1) > > binutils has rpath tags that point to its internal paths. there's no need > > for them to be listed in ld.so.conf. > > > > looks like a bug in uclibc's ldso. > > It is. I traced it back to an address problem in the aux vector table and > it only happens on 64-bit systems. (In reply to Anthony Basile from comment #5) > > I just hit it on i686 on one of my stages3. So we have an issue probably > across all uclibc arches: Actually there are two things going on here: 1) you need the transitive RUNPATH search patch referred to in comment 9 for the reasons explained in comment 11. This is across all arches. 2) on amd64, you also need to fix the borken RUNPATH issue.
Its unlikely that this problem is ever going to be backported to 0.9.33 branch since uclibc upstream is dead. The DT_RUNPATH is working for uclibc-ng, so I'm going to lift the mask from the profie. This will, unfortunately, break uclibc systems, but I've pretty much abandoned it in favor of uclibc-ng. I sent out a news letter recently. I'll leave this bug open as a reminder of the situation with uclibc. It is fixed for uclibc-ng.
(In reply to Anthony Basile from comment #20) > Its unlikely that this problem is ever going to be backported to 0.9.33 > branch since uclibc upstream is dead. The DT_RUNPATH is working for > uclibc-ng, so I'm going to lift the mask from the profie. This will, > unfortunately, break uclibc systems, but I've pretty much abandoned it in > favor of uclibc-ng. I sent out a news letter recently. > > I'll leave this bug open as a reminder of the situation with uclibc. It is > fixed for uclibc-ng. I dunno about it being fixed for uclibc-ng. I just updated my testing chroot with a recently-built uclibc-ng stage1 to uclibc-ng-1.0.18-r1, and ran smack into this issue again, where gas can't load libbfd-2.26.1.so, despite the fact it's sitting in the /usr/lib hierarchy. The uclibc-ng-1.0.17 version in a second uclibc-ng chroot seems to work fine, so this may be a breakage from 1.0.17 to 1.0.18? Going to try and test rebuilding binutils, if it gets that far...
(In reply to Joshua Kinard from comment #21) > (In reply to Anthony Basile from comment #20) > > Its unlikely that this problem is ever going to be backported to 0.9.33 > > branch since uclibc upstream is dead. The DT_RUNPATH is working for > > uclibc-ng, so I'm going to lift the mask from the profie. This will, > > unfortunately, break uclibc systems, but I've pretty much abandoned it in > > favor of uclibc-ng. I sent out a news letter recently. > > > > I'll leave this bug open as a reminder of the situation with uclibc. It is > > fixed for uclibc-ng. > > I dunno about it being fixed for uclibc-ng. I just updated my testing > chroot with a recently-built uclibc-ng stage1 to uclibc-ng-1.0.18-r1, and > ran smack into this issue again, where gas can't load libbfd-2.26.1.so, > despite the fact it's sitting in the /usr/lib hierarchy. The > uclibc-ng-1.0.17 version in a second uclibc-ng chroot seems to work fine, so > this may be a breakage from 1.0.17 to 1.0.18? > > Going to try and test rebuilding binutils, if it gets that far... Okay, it's binutils-config. It looks like the mask on binutils-config-5 isn't working in my chroot, so after the uclibc upgrade, it merged in binutils-config-5-r2, which is what broke things. Downgrading back to binutils-config-4-r4 fixes things. Anthony: Is the mask still in place, or was it recently removed in the uclibc profiles?
(In reply to Joshua Kinard from comment #22) > (In reply to Joshua Kinard from comment #21) > > (In reply to Anthony Basile from comment #20) > > > Its unlikely that this problem is ever going to be backported to 0.9.33 > > > branch since uclibc upstream is dead. The DT_RUNPATH is working for > > > uclibc-ng, so I'm going to lift the mask from the profie. This will, > > > unfortunately, break uclibc systems, but I've pretty much abandoned it in > > > favor of uclibc-ng. I sent out a news letter recently. > > > > > > I'll leave this bug open as a reminder of the situation with uclibc. It is > > > fixed for uclibc-ng. > > > > I dunno about it being fixed for uclibc-ng. I just updated my testing > > chroot with a recently-built uclibc-ng stage1 to uclibc-ng-1.0.18-r1, and > > ran smack into this issue again, where gas can't load libbfd-2.26.1.so, > > despite the fact it's sitting in the /usr/lib hierarchy. The > > uclibc-ng-1.0.17 version in a second uclibc-ng chroot seems to work fine, so > > this may be a breakage from 1.0.17 to 1.0.18? > > > > Going to try and test rebuilding binutils, if it gets that far... > > Okay, it's binutils-config. It looks like the mask on binutils-config-5 > isn't working in my chroot, so after the uclibc upgrade, it merged in > binutils-config-5-r2, which is what broke things. Downgrading back to > binutils-config-4-r4 fixes things. > > Anthony: Is the mask still in place, or was it recently removed in the > uclibc profiles? I removed the mask. DT_RUNPATH is working for me on amd64 and x86: amd64-uclibc-hardened-latest 2.25.1 # pwd /usr/x86_64-gentoo-linux-uclibc/binutils-bin/2.25.1 amd64-uclibc-hardened-latest 2.25.1 # ldd strip libbfd-2.25.1.so => /usr/lib/binutils/x86_64-gentoo-linux-uclibc/2.25.1/libbfd-2.25.1.so (0x2a2b623f000) libc.so.0 => /lib/libc.so.0 (0x2a2b5f94000) libz.so.1 => /lib/libz.so.1 (0x2a2b5d7e000) ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x2a2b67a7000)
