Sorry, this won't thread properly -- but I deleted the original before I realized I wanted to reply, so now I have to copy from the archives, and the archives don't have the right message-ids. :-/
Matthew Burgess wrote:
> On Wed, 2011-12-28 at 15:01 +0100, Pierre Labastie wrote:
>
> > I meant `current trunk' too. The change in version 3537 is not enough.
> > Here is what I have done (not checked on any other system than Debian,
> > but I do not see a reason why it would not work):
> > # if [ -f /lib/libc.so.6 ]; then
> > # libcLoc=/lib;
> > # elif [ -f /lib64/libc.so.6 ]; then
> > # libcLoc=/lib64;
> > # fi;
> > # libcVer="`/${libcLoc}/libc.so.6 | head -n1`"
> > libcExec="`find /lib /lib64 -name libc.so.6 -print`"
> > libcVer="`/${libcExec} | head -n1`"
>
> How odd. I was going to suggest you run some tests so I can figure out
> why r3537 isn't enough for Debian systems, but your version is a lot
> more compact and appears to work on my Fedora host too, so I may as well
> just drop it straight in. Thanks for the fix.
Why don't we do something a bit less fragile? The Linux ABI requires
that the dynamic linker be at the path /lib/ld-linux.so.2 (or
/lib64/ld-linux-x86-64.so.2 for 64-bit), so we could just use that fact,
along with ld.so's ability to print the soname -> filename resolution,
and ask /bin/ls which C library it's using:
ldd /bin/ls | awk '/libc\.so/ {print $3;}'
This works on 64-bit Ubuntu Hardy and an old 32-bit LFS. I don't have
anything else to test it on though. (It'd be nice if ld.so had a flag
to print the library it'd use for a given soname. Oh well.) We don't
actually care whether we're asking the 32-bit or 64-bit libc for its
version, since both should be the same.
pgpna1XNaGMGl.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
