Am Thursday 30 October 2008 13:26:27 schrieb Albert Hopkins:
> On Wed, 2008-10-29 at 20:47 -0400, Joshua Murphy wrote:
> > Hrm. I know just enough about python to get myself in trouble here...
> > but it looks like a python bug in magicking up the libc name and
> > version... but the below is WAY outside my level of practice with
> > python (it'll take re-reading and digging elsewhere a good few times
> > if I'm ever to make sense of it...
> >
> > ------------------
> > def libc_ver(executable=sys.executable,lib='',version='',
> >
> > chunksize=2048):
>
> <deleted>
> This is a very simple hack which simply doesn't work. Nice try. It's
> not so much portage's fault as it is Python.
>
> Basically what python is doing is opening it's executable
> (/usr/bin/python') and doing a egrep for
>
> (__libc_init)|(GLIBC_([0-9.]+))|(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)
>
> Then it finds the matches and tries to apply some "logic" to decide the
> best answer. On my system it's "GLIBC_2.0" and so platform.libc_ver()
> returns ('glibc', '2.0') whereas my actual libc is glibc 2.8.
>
> Obviously the person who wrote the function was trying to be
> cross-platform. Python runs on many different platforms, POSIX and
> non-POSIX. But the implementation is a bit "lazy" and, obviously,
> inaccurate.
That's utter bollocks and shows a fundamental misunderstanding of shared
libraries.
True, your installed glibc might be _package version_ 2.8, but the base
_interface_ (as in ABI) defined and supported by your shared glibc is version
2.0, which is the currently developed interface version (the interface is
also known as libc6), and that's what's actually of any interest to a
dynamically linked application.
Guess why applications dynamically linked against a 2.3 glibc can still be run
(without recompilation!) on a 2.8 glibc, and mostly vice-versa, except when
the application linked with a 2.8 glibc uses symbols which were introduced
later than the libc you're trying to run it on, but in that case these
symbols aren't marked as GLIBC_2.0 in your 2.8 glibc, but as GLIBC_2.4, for
example (stating that this symbol was first introduced and conforms to the
ABI that glibc 2.4 upwards have/has).
Do a readelf -a /lib/libc.so.6 to see what I'm talking about (symbol
versioning, and multiple symbols for one name differing in the symbol
version).
> ...
> So partial blame goes to both python and portage: python for it's shoddy
> implementation of platform.libc_ver() and portage for relying on it :-)
Again, this is utter bullshit. Python doesn't have a "shoddy" implementation
of libc_ver(), it just doesn't give you what you expect it to give you (it's
not a package manager, for gods sake), but rather what's of actual interest
to anyone doing application development.
--
Heiko Wundram
hackerkey://v4sw7CHJLSUY$hw5ln5pr7FOP$ck2ma9u7FL$w3DVWXm0l7GL$i65e6t3EMRSXb7ADORen5a26s5MSr2p-6.62/-6.56g5AORZ
