Created attachment 117775 [details] [review]
Install pyglib library in libdir/pygobject/pythonver instead of libdir

(Alternatively, this could be stored below the usr/lib/pythonX.Y/site-packages/gtk-2.0 namespace or the lib could be named libpyglib-pythonX.Y.so.)

I vote for libpyglib-pythonX.Y.so: no -rpath required and uses ldconfig cache.

Created attachment 118991 [details] [review]
Allow multiple pyglib in $libdir

The attached patch installs pyglib in $libdir/libpyglib-2.0-pythonX.Y.so, e.g. /usr/lib/libpyglib-2.0-python2.5.so, avoiding RPATHs in objects linking to it.

emilio@saturno:~$ ls /usr/lib/libpyglib-2.0-python2.*so
/usr/lib/libpyglib-2.0-python2.4.so  /usr/lib/libpyglib-2.0-python2.5.so

Created attachment 119030 [details] [review]
also correctly build the library for python-dbg

As Loïc pointed out to me on IRC, this isn't right because building with python-dbg the library will have the same name as with python. This new patch will name the library as libpyglib-2.0-pythonX.Y(-dbg).so, e.g.

libpyglib-2.0-python2.5.so
libpyglib-2.0-python2.5-dbg.so

I personally like the first patch better.  Both because it is much smaller / less intrusive and because I dislike this PYTHON_BASENAME mumbo-jumbo.  I'm suspicious about having anything to depend on executable name (that's what the patch does as I can understand).

Question: are there any possible problems about backwards compatibility?  Or should pkg-config just handle everything?  (People who ignore pkg-config and hardcode library name can be ignored.)

Darwin hard-codes the full path (not just the soname itself) when linking against a library. There's not the same idea as ldd or library search-paths, and the LD_* and DYLD_* env vars are a bit hairier too. So if one relocates or renames the shared lib, anything that linked against it at its old location/name becomes broken and has to be recompiled. I don't know of much (anything?) outside of pygobject itself that links against the lib at this time, so would be great to get this settled and stable while such changes only affect pygobject itself.

I fear my first patch wouldn't allow a separate pathname for the -dbg python variants we have.  If you actually intend to offer libpyglib as a public API/ABI for general consumption, then the second patch allows keeping the lib in /usr/lib too.

Concerning backward compatibility, yes either patch will break binaries linked in the past against a public lib dir with a non-versionned library; like Daniel, I think it would be best to address this the sooner rather than when many binaries link to it.

Eh, I'm not well versed in this type of stuff.  Is there any any replacement for the `basename ...` hack (python-config? something else?) or is it used like that in other libraries too?

Sorry, I don't know of a replacement for `basename $PYTHON`, that didn't seem too bad: PYTHON is always set by AM_PATH_PYTHON and basename will strip any directory from the pathname.  Perhaps the only downside is if someone calls configure with PYTHON=/usr/bin/python, in which case the filename wont be versionned; for this case, it'd be nice to have a nicer way to compute the versionned of the interpreter, but I don't know how.

(In reply to comment #10)
> [...] Perhaps the only downside is if someone calls
> configure with PYTHON=/usr/bin/python...

That's why I dislike depending on binary name.  However, I don't see a better way: trying to extract something from `python-config --includes` looks even worse.

So, unless someone can suggest a different approach, I'll just apply the second patch.

If one does PYTHON=/usr/bin/python, then the basename approach still does exactly what the user (says he:) wants: build the thing for "no specific python version". If he changes what /usr/bin/python is, he would always and everywhere-else-also have to make sure everything that expected or previously knew it to be version X was updated to know it as version Y.

However, I've never seen any other shared-library package do anything to make it easy to rename the lib itself for a debugging version. The Debian packaging standard for debugging-enabled libs appears to be to keep the same libname but put it in a separate location (I assume by using the normal --libdir ./configure flag). For example, libglib2.0-2 has the normal library:

/usr/lib/libglib-2.0.so.0
/usr/lib/libglib-2.0.so.0.2000.1

while libglib2.0-0-dbg has:

/usr/lib/debug/usr/lib/libglib-2.0.so.0.2000.1

I think /usr/lib/debug is completely unrelated to this.

What is placed in /usr/lib/debug are the stripped symbols only. Debuggers (e.g. gdb) will automatically load the symbols from that location, but that doesn't solve the case for libpyglib, since /usr/lib/debug isn't versioned (so you still can't have one pyglib lib for each python version) and /usr/lib/debug isn't in the library path.

What we need is to a way to have several libpyglib in /usr/lib, and you can only do that by naming them after the python version. The alternative is to put them in some /usr/lib subdirectories, but that will mean you need RPATHs AFAIUI.

I totally support python-version versioning (I manage the python and gnome packages on a system that has concurrently-installed different versions of python and therefore absolutely requires non-colliding sonames for anything that is built against them). I just don't see the need in Comment #5 to make it more complicated than that (additional -dbg component of the lib name if that's how python interp is named), and as example that other libs use (apparently) rpath instead of different soname for debugging versions.

Are python2.6 and python2.6-dbg (either their front-end interpretters or back-end shared libs) incompatible with each other? How would libpyglib differ depending on which of those two was used when building it? I don't recall seeing separate compiled (.so) python module collections for each...python itself seems to be content having one lib/pythonX.Y for each python version, so I'm surprised that this python-module-related shared library needs to have a more specifically varianted name.

Hey Daniel; I agree we could use libdir tricks for this case, but it would be fragile because on a typical system multiple incompatible libraries would be installed with the same SONAME.  Also, we try to avoid rpath-es in general.

python2.x and python2.x-dbg are not interchangeable, you need to build Python extensions specially for the -dbg versions as it will call different functions on module initialization (it loads the _d.so instead of the .so).  For a sample symptom of what happens if you try to use with a python-dbg an extension which wasn't built for -dbg (by renaming an extension to _d.so for instance), you can check:
http://bugs.debian.org/468130
>>> import gobject
Traceback (most recent call last):

+ Trace 214802

I'm officially lost here.  Can anyone clearly summarize which patch they prefer and give a very short (2 sentences?) and understandable for non-packagers summary?

Since I haven't received any response, I'm committing the patch which, as I understood, have more support.  Seems to work as intended.