Le mardi 09 octobre 2007 à 12:00 +0200, Joop Stakenborg a écrit : > 2007/10/8, Josselin Mouette <[EMAIL PROTECTED]>: > > There must be a -lpython2.4 added specifically in the build process. > > I am sorry, still don't get it. Using ldd I see the following: > $ ldd /usr/share/python-support/python-libhamlib2/_Hamlib.so > libpython2.4.so.1.0 => /usr/lib/libpython2.4.so.1.0 (0xb7d9f000) > > Adding -lpython2.4 won't help, because we do dynamic linking. We still > end up with python2.4 dependencies. The "Python binding" section in > bindings/Makefile adds the following rules: > > PYTHON_LDFLAGS = -L/usr/lib/python2.4/config -lpython2.4 > > Which looks okay to me. We can only achieve what you want by doing > static linking, am I right?
Sorry, I haven't been clear. What I wanted to say is that there must be something adding -lpython2.4 in the build process and that you should *remove* it. If it is added by the PYTHON_LDFLAGS up there, it is exactly the thing to remove. > > It is a system in which you build the module once for each available > > python version, like most python extensions are doing currently. > > This is a task for upstream. Currently they have decided to build > against python2.4, which is okay for me, it is also the default in > Debian. It is the default, but only currently; this is why the current standard is to build an extension for each available python version. Anyway, if upstream chose to hardcode the version to 2.4, this is a very bad thing because we cannot keep the package when 2.5 becomes the default. You could still change the package to require only python2.4 (that means doing this also in the shebangs) and rename it to python2.4-libhamlib2, but it would still lose its usefulness when 2.5 becomes the default. If it turns out that it can build with python2.5, you should make it build once for each python version, or, if it isn't possible, change the python2.4 references to be `pyversions -d`, so that we can just binNMU the package when python 2.5 becomes the default. > I don't have the knowledge to do a multi-build, neither has > upstream. Unless you can provide patches, which I can commit to > upstream CVS. This is trivial when upstream uses distutils instead of custom hackery (it's just a loop), and not too complicated if upstream uses automake correctly. Cheers, -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
