Albert Hopkins wrote:
On Wed, 2008-09-24 at 22:34 +0200, Maarten wrote:
Albert Hopkins wrote:
# ldd e2fsck/e2fsck
linux-gate.so.1 => (0xb8033000)
libc.so.6 => /lib/libc.so.6 (0xb7edb000)
/lib/ld-linux.so.2 (0xb8034000)
Ehm, exactly. So yes, it uses less libraries than before, but in no way
is this a real statically linked binary:
This is true, but it is sufficiently static enough. Pretty much any
Linux shipped within the past 10 years or so has GNU libc 2 .x (libc 6),
so the dependencies are satisfied.
Ah ? Are there no major difference between recent glibc versions ? I did
not know that versions are so much compatible.
If you really really need static then:
No, it worked. However, the com_err library gave us no end of grief
today. Mount was broken, fetchmail was broken, etc. And reemerging
com_err yielded no results, the error
"libcom_err.so.2: cannot handle TLS data"
persisted like a real plague. I finally fixed it, but am unsure how. I
think reemerging an ancient version together with ss in the exact same
version did the trick. But something is badly broken-- com_err insists
on running revdep-rebuild, but running that does NOT report problems
related to any of the problematic binaries... :-(
As witnessed by, for instance, this:
master sys-libs # mkfs.ext2 --help
mkfs.ext2: error while loading shared libraries: libuuid.so.1: cannot
handle TLS data
master sys-libs # revdep-rebuild --pretend --ignore
Checking reverse dependencies...
<snip>
Checking dynamic linking consistency...
broken /usr/lib/apache2-extramodules/libphp4.so (requires libpdf.so.2)
broken /usr/X11R6/lib/apache2-extramodules/libphp4.so (requires
libpdf.so.2)
broken /opt/blackdown-jre-1.4.2.01/lib/i386/libjsoundalsa.so
(requires libasound.so.2)
broken /opt/blackdown-jdk-1.4.2.03/jre/lib/i386/libjsoundalsa.so
(requires libasound.so.2)
done.
<snip>
All prepared. Starting rebuild...
emerge --oneshot --nodeps --pretend --ignore
=dev-java/blackdown-jdk-1.4.2.03-r12 =dev-java/blackdown-jre-1.4.2.01-r1
=dev-php/mod_php-4.3.10
In other words, no sign at all about this broken stuff. Same goes for
fetchmail, but that has been reemerged so I cannot reproduce it anymore.
All in all, it has been a VERY BAD week for Gentoo from my perspective.
Which is a shame really, because I _want_ to love Gentoo... But... :-(
Another very bad thing which really bites us with our older Gentoo
servers is the fact that having the CHOST set to *i386-* seems to
harshly break any hope of a viable upgrade path. Figure that-- the main
reason we chose Gentoo was, in fact, the possibility to seamlessly
upgrade and thus stay up to date forever. That CHOST has killed that
hope. Now IF someone back in 2004 had mentioned (or had known?) this
fact we would not have fallen in this trap. But now, our management is
pushing real hard to switch to redhat or some other 'terrible choice'.
I really really get angry and disappointed whenever I think about this
situation nad how trivially simple it could have been avoided... :-(
I even think that the com_err thingy has some relations to this. Because
'emerge world' has been effectively cut off for us, many many upgrades
can be done only halfway, and these library problems indirectly stem
from that.
If someone knows a solution to the CHOST=i386 problem that doesn't
involve an 'emerge --emptytree world', I would LOVE to hear it...!
Thanks,
Maarten
