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 => (0xffffe000)
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 => (0xffffe000)
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 => (0xffffe000)
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 => (0xffffe000)
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
