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

Re: Dependencies on shared libs, take 2

On Thu, Jun 07, 2007 at 08:44:32PM +0200, Pierre Habouzit wrote:
> On Thu, Jun 07, 2007 at 07:15:22PM +0200, Bernhard R. Link wrote:
> > * Julien Cristau <jcristau@debian.org> [070607 18:04]:
> > > > Reality is that this build must fail with a proper warning, so that the
> > > > maintainer can decide if this is an excption and ok or whether he should
> > > > cluebat upstream about a what soname means.

> > > Reality is that libs export private symbols (not part of the API, and
> > > not used by anything), and a private symbol disappearing shouldn't force
> > > a SONAME change.

> > Having a private symbol before was already a bug that the Debian
> > mantainer should have caught. If it happens that such things (which
> > theoretically should detectable by some script) are not catched, then
> > changing the semantics of symbols is even more likely to be missed.
> > (And thus we have to expect quite some breakage from less strict
> > dependencies).

>   symbol visibility support in gcc is not that old, and many upstream
> don't use it (yet). For them there is many many many private symbols in
> the libraries, and well, they don't matter at all.

It's been possible to avoid the export of symbols for years using version
scripts, which most libraries also ought to be using anyway.

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/

Reply to: