On Thu, 2011-09-08 at 00:27 +0100, Vinay Sajip wrote:
> On my builds, libpython2.7.so.1.0 _is_ showing up in the
metadata:
> [david@surprise pyapi]$ ldd python.so | grep libpython
> libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
> (0x00007f9a6e3d1000)
> [david@surprise pyapi]$ eu-readelf -d python.so | grep libpython
> NEEDED Shared library: [libpython2.7.so.1.0]
But not here :-(
vinay@zeta-oneiric-scratch:~/projects/gcc-python-plugin$ ldd python.so | grep libpython
vinay@zeta-oneiric-scratch:~/projects/gcc-python-plugin$ eu-readelf -d python.so | grep
libpython
vinay@zeta-oneiric-scratch:~/projects/gcc-python-plugin$
> I wonder why it's present for my builds, and not for yours. What does
> python-config --ldflags
> show for you?
>
>
> On this Fedora 15 x86_64 box I get:
> [david@surprise pyapi]$ python-config --ldflags
> -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic
vinay@zeta-oneiric-scratch:~/projects/gcc-python-plugin$ python-config --ldflags
-L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker
-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
The difference between our machines' --ldflags seems to be that your
machine has these additional arguments:
-L/usr/lib/python2.7/config -Wl,-O1 -Wl,-Bsymbolic-functions
What is the content of that -L directory? In particular, does it contain
a libpython2.7.a static library? On Fedora, we don't ship the static
library, and that directory (64-bit multilib version) contains the
following on my machine (from python-libs-2.7.1-7.fc15.x86_64):
[david@surprise ~]$ ll /usr/lib64/python2.7/config
total 124
-rw-r--r--. 1 root root 2169 Apr 12 12:15 config.c
-rw-r--r--. 1 root root 1507 Apr 12 12:15 config.c.in
-rwxr-xr-x. 1 root root 7122 Apr 12 12:15 install-sh
lrwxrwxrwx. 1 root root 21 Aug 8 09:54 libpython2.7.so
-> ../../libpython2.7.so
-rw-r--r--. 1 root root 64924 Apr 12 12:15 Makefile
-rwxr-xr-x. 1 root root 7444 Apr 12 12:15 makesetup
-rw-r--r--. 1 root root 6504 Apr 12 12:15 python.o
-rw-r--r--. 1 root root 18140 Apr 12 12:15 Setup
-rw-r--r--. 1 root root 368 Apr 12 12:15 Setup.config
-rw-r--r--. 1 root root 41 Apr 12 12:15 Setup.local
So I think that what might be happening is that in your machine's builds
the plugin has been statically linking against libpython2.7.a, and only
linking against some subset of that library's symbols, rather than all
of them.
http://bugs.python.org/issue4434 alludes to this, and suggests "using
--whole-archive option when linking with the static library".
Presumably "eu-readelf -s python.so" shows some of the Py* python API
symbols; is the "Ndx" field of those symbols "UNDEF" (meaning that
they're to be pulled in from a dynamic library), or are they some
integer value (meaning that they've been statically linked inside
the .so file)?
I don't know whether or not I've accidentally introduced a Fedora-ism
into the Makefile, but given that it appears to work on Gentoo and
Mandriva, perhaps there's something about Ubuntu that's breaking things?
(the Makefile assumes that python-config --ldflags are what's need to
link)
[snip full compilation flags]
For some odd reason, the -I/usr/include/python2.7 shows up twice:
vinay@zeta-oneiric-scratch:~/projects/gcc-python-plugin$ python-config --cflags
-I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O2 -Wall -Wstrict-prototypes
I don't think that's an issue; I believe that this just leads to
duplicate adjacent values in a prioritized list, which is essentially
idempotent.
Dave