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