[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: versioned symbols in shared libraries (upstream != Debian)

On Tue, Mar 14, 2006 at 01:25:21AM +0100, Christian Hammers wrote:

> During the last month I have build my libmysqlclient15 with
> shared symbols that looked in "objdump -T" like:
>   0013a154 g    DO .bss   00000004  MYSQL_5.0   my_dont_interrupt
>   00026d70 g    DF .text  000002fa  MYSQL_5.0   my_strntoll_8bit
>   00015730 g    DF .text  00000025  MYSQL_5.0   my_no_flags_free

> Now MySQL finally closed my bug report to them and provides symbols
> in their upstream source. Sadly they look like:
>   0000f280 g    DF .text  0000000b  libmysqlclient_15 mysql_row_tell
>   0000f4d0 g    DF .text  00000043  libmysqlclient_15 mysql_escape_string
>   0000da30 g    DF .text  000000e1  libmysqlclient_15 mysql_slave_send_query

> This is bad, right? If I would just use them all the previously built
> binaries would stop linking and if I stay with mine, no non-Debian
> dynamically linked binary would run on Debian, right? Any ideas?

Yes, this is a backwards-incompatible ABI change.  If libmysqlclient15 had
been present in sarge, such a change without a rename of the library package
would be a release-critical bug for etch; since it wasn't, it's only
severity: important, but either way all packages built against the previous
symbol versions would have a release-critical bug requiring a rebuild.

And changing the package name is actually the easiest way to make sure that
no RC-buggy reverse-dependencies are overlooked.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: