On a system with 2.2.4-rX I tried updating to 2.2.5, which proved fatal. I do not have the complete build log, but from the end: sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory !!! /usr/include/bits/sigaction.h sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory !!! /usr/include/bits/syscall.h sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory !!! /usr/include/bits/signum.h sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory !!! /usr/include/bits/sigset.h It would appear that what should have been an atomic operation (installing a few of the most vital shared libraries) is not, and that results in the above warnings. To restore the system, cp /lib/libdl-2.2.4.so /lib/libdl.so.2, ln -sf libnsl-2.2.4.so libnsl.so.1 ln -sf libresolv-2.2.4.so libresolv.so.2 and possibly other symlinks are needed.
What version of Portage are you using? I emerged my glibc-2.2.5 while running X with absolutely no problems.
Possibly these lines in src_install() are causing problems? You could try removing them and doing a test merge again. rm ${D}/lib/ld-linux.so.2 rm ${D}/lib/libc.so.6 rm ${D}/lib/libpthread.so.0 It's also possible that if things (symlinks/libraries) are not merged in a "correct" order, things will blow up. Something to think about; let me know what you find.
It probably has to do with the order of the symlinking... when installing glibc it is vital to link libc.so.6 first, followed by libdl.so.2 the others should be able to follow in any order... I am not yet familiar with the ebuild system so I can't offer to correct the ebuild itself.
Could not reproduce error. System is uptodate as of requirements based on rsync from ~10AM MST. Could not reproduce error using ebuild. ebuild sys-libs/glibc/glibc-2.2.5.ebuild install ebuild sys-libs/glibc/glibc-2.2.5.ebuild qmerge No defunct anything, and libdl.* is OK, no errors or failed tests anywhere. ldd --version ldd (GNU libc) 2.2.5 ... Have script capture of both build processes, as well as 2.2.5 package available with md5 sum on request.
Why are these lines in the ebuild? rm ${D}/lib/ld-linux.so.2 rm ${D}/lib/libc.so.6 rm ${D}/lib/libpthread.so.0 those are just symlinks, which should either a) have already been replaced by the make install or b) will be regenerated by ldconfig in just a moment.
masked out for now; changing to a "normal" bug.
Ok, I have a working ebuild, I submitted it as glibc-2.2.5-r1.ebuild basically it makes sure that all the symlinks for the libraries are moved away before qmerging and then moves them all in after the binaries are installed to ensure system continuity.
forgot, the ebuild is available at http://www.lostlogicx.com/ebuilds/glibc-2.2.5-r1.ebuild
we haven't yet confirmed that this is a symlink problem. I'm waiting for karltk to perform a test and log the build process first.
I'm sure it is a symlink problem... of course I'm not god or anything... but when I tried to build with the original ebuild it did what happened to karltk, but with my ebuild it worked great... so...
ok, neat.
yes, it does look like a symlink problem. I just noticed that on karltk's system, 2 symlinks got installed before the libs got installed which would have broke some important symlinks. Will fix now.
a version of glibc-2.2.5-r1.ebuild with the same functionality at Brandon's version has been added to CVS. Closing this bug, and filing a new one for Portage since Portage should handle this tricky stuff for us by ensuring that symlinks are merged *after* the things that they point to. We could still potentially have problems with 2 layers of symlinks in /lib if the symlinks get copied back in the wrong order.
