Hi, I've stomped on this bug record, and as it is something I have already encountered I thought I'd give some advice.
Le mardi 01 août 2006 à 09:58 +0100, Mark Baker a écrit : > On Tue, Aug 01, 2006 at 09:40:26AM +0200, Harald Dunkel wrote: > > > Upstream uses a different soversion for libpcre than Debian. > > RedHat and Suse are using upstream's soversion, i.e. packages > > built on these distros cannot be run on Debian. > > Debian have always built libpcre as a shared library, starting with > version 1.x which we used a soname of libpcre.so.1 for; after 3.x, for > which we used a soname of libpcre.so.3, we haven't had to change the > version number as the interface has been compatible. It is too late now, but you should have warned upstream as soon as you were affecting a soname to the library. It would at least be a very good idea to convince them to jump directly to libpcre.so.4 if the interface ever changes again. To avoid such issues, the standard method is now to make a Debian-specific soname like libfoo.so.0d (note the d at the end). > > I would suggest to add a symbolic link to libpcre3, providing > > upstream's soversion. > > Will that work? I thought the soname compiled in to the library had to > match as well. Yes, that will work. At runtime, the GNU dynamic linker only looks for the filename corresponding to the NEEDED field. But you shouldn't forget to conflict with libpcre1 if you do that. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
