Re: [gentoo-user] Problem building statically linked e2fsprogs
Hello (Original post too long to quote) How about building it dynamically and taking all the needed libraries as well? I had similar problem (I needed fsck.ext3 in my init ramdisk) and I just used ldd to find out what does it need. You can test if it has enough by copying the thinks indo a directory, chrooting there and trying out if it runs. I hope it helps -- When all else fails, EAT!!! Michal 'vorner' Vaner pgpiVJj0anDDP.pgp Description: PGP signature
Re: [gentoo-user] Problem building statically linked e2fsprogs
On 25 Sep 2008, at 20:02, Erik Hahn wrote: I don't know much about servers so this might be rather stupid, but: What about dismounting the driver and fsck'ing it in another computer? I think the problem is that the drive (the server) is in a physically remote location. (from the original message: "... the only way to get it up again (no IT people at the location) was by talking someone through a process...") Nevertheless, one can't help thinking the machine could be booted from a Knoppix CD. Stroller.
Re: [gentoo-user] Problem building statically linked e2fsprogs
I don't know much about servers so this might be rather stupid, but: What about dismounting the driver and fsck'ing it in another computer? -Erik -- hackerkey://v4sw5hw2ln3pr5ck0ma2u7LwXm4l7Gi2e2t4b7Ken4/7a16s0r1p-5.62/-6.56g5OR
Re: [gentoo-user] Problem building statically linked e2fsprogs
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... 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. 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
Re: [gentoo-user] Problem building statically linked e2fsprogs
On Wed, 2008-09-24 at 22:34 +0200, Maarten wrote: > Albert Hopkins wrote: > > The grep package has a "static" USE flag. e2fsprogs does not. So > > enabling the static USE flag has no effect on e2fsprogs. > > Ehm, how do you figure that? It surely displays the "static" USE flag: > > thoughtpad ~ # emerge -pv e2fsprogs > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls -static" 0 kB > Sorry, I am using a later version of e2fsprogs that does not have the "static" USE flag. I didn't know that earlier versions did have it but, as another poster said, there is a bug for the package where use of the "static" flag doesn't work. > So I would assume at this point the package is broken in this respect. > > > The easiest (easier?) thing to do would be to compile e2fsprogs > > statically by hand and copy over the resulting binary > > Good idea... well, maybe... > > > # tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz > > # cd e2fsprogs-1.x.x > > # ./configure --enable-static > > # make > > # 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. If you really really need static then: # cd e2fsck # make e2fsck.static # ldd e2fsck.static not a dynamic executable
Re: [gentoo-user] Problem building statically linked e2fsprogs
Daniel Pielmeier wrote: Maarten schrieb am 24.09.2008 21:39: Can anyone help with this ? Does this package not support building static ? The USE flag is there for a reason, no? Did I take the wrong approach here ? What is up with this [damn] package ?!? http://bugs.gentoo.org/show_bug.cgi?id=232115 gives some information about this issue. Ah, that explains it. Still, not too nice a fix they did on this. Instead of really addressing the issue, simply "dropped USE=static". (But what do I know, maybe it's truely quite complicated) Anyway, I'll shut up before my frustration of today airs too much. :-) Regards, Maarten
Re: [gentoo-user] Problem building statically linked e2fsprogs
Albert Hopkins wrote: On Wed, 2008-09-24 at 21:39 +0200, Maarten wrote: Hi List, [...] # Grep works fine... [EMAIL PROTECTED] ~ $ ldd /bin/grep linux-gate.so.1 => (0xe000) libc.so.6 => /lib/libc.so.6 (0xb7e42000) /lib/ld-linux.so.2 (0xb7f96000) thoughtpad ~ # USE="static" emerge -v grep [snip] [EMAIL PROTECTED] ~ $ ldd /bin/grep not a dynamic executable # But e2fsprogs doesn't... [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck linux-gate.so.1 => (0xe000) libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000) libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000) libc.so.6 => /lib/libc.so.6 (0xb7d55000) /lib/ld-linux.so.2 (0xb7ee8000) thoughtpad ~ # USE="static" emerge -v e2fsprogs [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB [snip] Enabling ELF shared libraries [snip] checking whether linker accepts -static... yes [snip] >>> Completed installing e2fsprogs-1.40.9 into /var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/ # After that, no change, however... [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck linux-gate.so.1 => (0xe000) libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000) libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000) libc.so.6 => /lib/libc.so.6 (0xb7e33000) /lib/ld-linux.so.2 (0xb7fc6000) The grep package has a "static" USE flag. e2fsprogs does not. So enabling the static USE flag has no effect on e2fsprogs. Ehm, how do you figure that? It surely displays the "static" USE flag: thoughtpad ~ # emerge -pv e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls -static" 0 kB So I would assume at this point the package is broken in this respect. The easiest (easier?) thing to do would be to compile e2fsprogs statically by hand and copy over the resulting binary Good idea... well, maybe... # tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz # cd e2fsprogs-1.x.x # ./configure --enable-static # make # 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: # ldd e2fsck/e2fsck linux-gate.so.1 => (0xe000) libc.so.6 => /lib/libc.so.6 (0xb7e32000) /lib/ld-linux.so.2 (0xb7f86000) # file e2fsck/e2fsck e2fsck/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped However, since this might still perform much better, I tested it... and indeed, it does the job (despite different glibc versions between the build host and the bad server): broken_server ~ # /sbin/e2fsck e2fsck: error while loading shared libraries: libcom_err.so.2: cannot handle TLS data broken_server ~ # ./e2fsck Usage: ./e2fsck [-panyrcdfvstDFSV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Thank you, Maarten
Re: [gentoo-user] Problem building statically linked e2fsprogs
Maarten schrieb am 24.09.2008 21:39: Can anyone help with this ? Does this package not support building static ? The USE flag is there for a reason, no? Did I take the wrong approach here ? What is up with this [damn] package ?!? http://bugs.gentoo.org/show_bug.cgi?id=232115 gives some information about this issue. Regards, Daniel
Re: [gentoo-user] Problem building statically linked e2fsprogs
On Wed, 2008-09-24 at 21:39 +0200, Maarten wrote: > Hi List, > [...] > > # Grep works fine... > [EMAIL PROTECTED] ~ $ ldd /bin/grep > linux-gate.so.1 => (0xe000) > libc.so.6 => /lib/libc.so.6 (0xb7e42000) > /lib/ld-linux.so.2 (0xb7f96000) > > thoughtpad ~ # USE="static" emerge -v grep > [snip] > > [EMAIL PROTECTED] ~ $ ldd /bin/grep > not a dynamic executable > > # But e2fsprogs doesn't... > > [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck > linux-gate.so.1 => (0xe000) > libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000) > libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000) > libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000) > libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000) > libc.so.6 => /lib/libc.so.6 (0xb7d55000) > /lib/ld-linux.so.2 (0xb7ee8000) > > thoughtpad ~ # USE="static" emerge -v e2fsprogs > [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB > [snip] > Enabling ELF shared libraries > [snip] > checking whether linker accepts -static... yes > [snip] > >>> Completed installing e2fsprogs-1.40.9 into > /var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/ > > # After that, no change, however... > [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck > linux-gate.so.1 => (0xe000) > libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000) > libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000) > libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000) > libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000) > libc.so.6 => /lib/libc.so.6 (0xb7e33000) > /lib/ld-linux.so.2 (0xb7fc6000) > The grep package has a "static" USE flag. e2fsprogs does not. So enabling the static USE flag has no effect on e2fsprogs. The easiest (easier?) thing to do would be to compile e2fsprogs statically by hand and copy over the resulting binary # tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz # cd e2fsprogs-1.x.x # ./configure --enable-static # make # ldd e2fsck/e2fsck linux-gate.so.1 => (0xb8033000) libc.so.6 => /lib/libc.so.6 (0xb7edb000) /lib/ld-linux.so.2 (0xb8034000)
[gentoo-user] Problem building statically linked e2fsprogs
Hi List,
I'm in a bit of trouble. A server or ours has a broken e2fsck because it
is linked to a library version that doesn't exist anymore. Yes, I should
have fixed this before-- but alas, I obviously didn't... :-(
Tonight, the server had a hard crash and the only way to get it up again
(no IT people at the location) was by talking someone through a process
wherein I replaced e2fsck by /bin/true so it would not complain at boot
(where it would remain in an inaccesible state, with a panic shell).
So it is up and running again. All /seems/ fine, for now at least...
However, we must certainly assume the disk is in a dirty state so I
really do not want to do more than the bare minimum to it. So emerging
isn't a real good idea. Even then, I still tried. But it seems that
-despite the state of the bug(s) about e2fsprogs which are in
{resolved,fixed} state I cannot get e2fsprogs to compile AT ALL.
I've tried 10 different versions, etc., etc. To no avail. (Error below)
I believe looking at google and forum entries e2fsprogs on gentoo has a
*terrible* track record of late by the way, but maybe that is just me.
Things get more complicated fast, because this server has a CHOST i386
therefore -unless someone tells me otherwise- I cannot update glibc, and
practise has taught us to not upgrade packages/libs left and right
because you invariably end up, at revdep-rebuild time, with dependencies
which are unsolvable "unless...". And it is the "unless" (meaning emerge
-e world) which is unacceptable for this (or any production-) server...
It crashes on the "../../lib/libuuid.so: undefined reference to
`___tls_get_addr'". The two bugzilla entries that apply basically tell
me to rebuild from scratch, which I cannot do for reasons outlined
above. (http://bugs.gentoo.org/204102 & http://bugs.gentoo.org/232743)
-in short-
So as to avoid any further messing with the box I opted for building a
statically linked e2fsck binary on another box and copy it. However, I'm
having no luck with that. I can build static binaries fine for other
packages, but e2fsprogs refuses to build a static version.
(It builds, but the result is still dynamically linked)
Can anyone help with this ? Does this package not support building
static ? The USE flag is there for a reason, no? Did I take the wrong
approach here ? What is up with this [damn] package ?!?
# Grep works fine...
[EMAIL PROTECTED] ~ $ ldd /bin/grep
linux-gate.so.1 => (0xe000)
libc.so.6 => /lib/libc.so.6 (0xb7e42000)
/lib/ld-linux.so.2 (0xb7f96000)
thoughtpad ~ # USE="static" emerge -v grep
[snip]
[EMAIL PROTECTED] ~ $ ldd /bin/grep
not a dynamic executable
# But e2fsprogs doesn't...
[EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000)
libc.so.6 => /lib/libc.so.6 (0xb7d55000)
/lib/ld-linux.so.2 (0xb7ee8000)
thoughtpad ~ # USE="static" emerge -v e2fsprogs
[ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB
[snip]
Enabling ELF shared libraries
[snip]
checking whether linker accepts -static... yes
[snip]
>>> Completed installing e2fsprogs-1.40.9 into
/var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/
# After that, no change, however...
[EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000)
libc.so.6 => /lib/libc.so.6 (0xb7e33000)
/lib/ld-linux.so.2 (0xb7fc6000)
[EMAIL PROTECTED] ~ $ ls -la /sbin/e2fsck
-rwxr-xr-x 1 root root 159896 Sep 24 21:17 /sbin/e2fsck
[EMAIL PROTECTED] ~ $ file /sbin/e2fsck
/sbin/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
Thanks in advance for any insights...
Maarten
