FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-11-2007, 09:03 AM
Julien Cristau
 
Default -Wl,--as-needed considered possibly harmful

On Mon, Dec 10, 2007 at 18:29:36 +0100, Raphael Hertzog wrote:

> On Mon, 10 Dec 2007, Sune Vuorela wrote:
> > Isn't the new dpkg-shlipdeps warning about symbols it can't find ?
>
> Only if the library has a SONAME. This is intended so that
> perl/python/apache modules do not generate bad warnings: they rely on the
> binary dlopening them to provide the symbols (and it's okay that way).
>
> So the problem might still be missed on some plugins without SONAME.
>
And for plugins/modules with an SONAME, it will be missed in the noise
of warnings about symbols provided by the main binary/library.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-11-2007, 09:08 AM
Julien Cristau
 
Default -Wl,--as-needed considered possibly harmful

On Mon, Dec 10, 2007 at 17:45:27 +0100, Josselin Mouette wrote:

> When many of the types used by GTK+ are those provided by GLib, it
> sounds wrong to ask developers to include the GLib headers to have these
> types available.
>
It sounds wrong not to ask them to use -lglib-2.0 themselves if they
call glib functions.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-11-2007, 09:08 AM
Josselin Mouette
 
Default -Wl,--as-needed considered possibly harmful

Le lundi 10 décembre 2007 Ã* 18:24 +0000, Neil Williams a écrit :
> I don't have a problem with libglib2.0-0 in gtk+2.0.pc - it may well be
> correct to have that one in the pkgconfig because gtk headers define
> variables in terms of Glib typedefs. (I have to do the same with libqof1).
>
> The actual string is:
> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
> -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
> -lglib-2.0

And it used to be much longer. We’ve been working on reducing it and it
is still work in progress.

> 1. Glib: gmodule2.0 (and it's variants) shouldn't export -ldl. This is
> minor because it's a libc6 lib anyway so it doesn't cause an extra
> dependency but it will be the only "unwanted" link in the next version
> of libqof1 now that I've fixed the others.
>
> 2. Gtk+2.0 really shouldn't export gmodule. Even if there is a reason
> for lglib2.0, there is no reason for -lgmodule. It is trivial to omit
> this linkage from the gtk+2.0.pc file.

Both sound right, although this is something that needs some more
checking.

> 3. Ditto for gobject although I might be wrong on that one.

Yes, GObject provides the object model and I don’t think we can omit it.

> 4. Gtk+2: There is no need, as I see it, for atk, m, pangocairo, pango
> or cairo to be Requires: in gtk+2.0.pc - these should be
> Requires.private: instead.

IIRC most of them are used in either macros or for the types they
provide. Maybe some of them could be omitted, but not all of them.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 12-11-2007, 09:53 AM
Romain Beauxis
 
Default -Wl,--as-needed considered possibly harmful

Le Monday 10 December 2007 20:03:50 Pierre Habouzit, vous avez écrit*:
> > Perhaps the "absurd and wrong" part is that pkg-config does not
> > provide a way to distinguish between use cases, and that the name for
>
> * Wrong, please read pkg-config(1) and think again.
>
> $ pkg-config tokyocabinet --libs
> -ltokyocabinet
> $ pkg-config tokyocabinet --libs --static
> -ltokyocabinet -lz -lpthread -lm -lc
> $ grep Libs /usr/lib/pkgconfig/tokyocabinet.pc
> Libs: -L${libdir} -ltokyocabinet
> Libs.private: -lz -lpthread -lm -lc
>
>
> * pkg-config *is* perfectly suited for that matter actually, and
> "broken" pkgconfig upstreams are this trivial to fix. My upstream for
> tokyocabinet uses in a tokyocabinet.pc.in:
> * Libs: -L${libdir} -ltokyocabinet @LIBS@
> the fix is just to put the @LIBS@ onto Libs.private and be done with it.
> Upstreams using pkg-config are actually the first _easy_ targets to fix
> the dependency issues _they_ generate in others binaries. And there is
> no reason no to fix those when it's easy to do so.

Right, so now I now how to fix #395185 .. Seems I lacked some knowledge about
pkg-config :-)


Romain
 
Old 12-26-2007, 03:12 AM
Steve Langasek
 
Default -Wl,--as-needed considered possibly harmful

On Fri, Dec 21, 2007 at 10:55:32AM +0000, Neil Williams wrote:
> On Thu, 20 Dec 2007 21:44:19 -0800
> Steve Langasek <vorlon@debian.org> wrote:

> > Consider two libraries, libfoo and libbar. libfoo depends on libbar,
> > references functions from it and uses some of libbar's types in its own
> > exported API.

> > We assume the Debian-style libbar-dev, which ensures that the libbar headers
> > match the version of libbar.so on the system.

> > The pkg-config technique guarantee that, when an application links against
> > libfoo, it is also linked against libbar. Because of the preceding, this
> > guarantees that the application is linked against the version of libbar
> > whose ABI matches that of the headers used when building the application.

> > But *nothing* here guarantees that the version of libbar the application is
> > linked against has the same ABI as the one libfoo itself linked against!

> ... until both the application and libfoo are rebuilt. So the issue
> here is triggering rebuilds of reverse dependencies of libbar?

No. That doesn't cause previously released binaries to blink out of
existence.

What's required is to ensure that there's a package rename each time
libfoo's ABI changes, including when the libfoo ABI change is caused by type
changes in the underlying lib. This is essentially the general case of the
c102, c2, c2a, and ldbl transitions that we've been through for compiler
changes over the past few years; in theory we should be able to accomplish
these transitions for libraries with fewer reverse-dependencies than
libstdc++ with significantly less pain, as long as library maintainers are
forewarned.

But once the package name change is handled, the rebuild of reverse-deps
follows naturally.

> Maybe I've got this wrong but there would appear to be a few methods to
> fix this:
> 1. Incorporating the libbar SONAME into the libfoo package SONAME - as
> Simon Richter recommended - this could quickly end up with
> libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that
> this would actually help anyone if, for example, libbaz0 migrates to
> libbaz1 in a way that completely breaks libbar2.

Then either libbar2 becomes libbar3 at the same time, or libbar becomes
unsupported (and the stack above it has to be ported or else it's not
releasable), or libbaz needs to support symbol versioning to permit
coexistence of the two versions in the same address space.

> 2. A rebuild trigger mechanism that is separate from the library SONAME
> and the pkg-config files - an automated version of what happens now for
> requesting binNMU's ? Not as easy as it may sound - there's no
> guarantee that libfoo *can* build against libbar2.

Wrong for the reasons stated above.

> 3. A build-time hook that checks the entire dependency chain for
> duplicates and fails if a freshly built binary ends up linked to two
> versions of one source? (i.e. requiring a bug in whichever package is
> using libbar1 to upgrade to libbar2). That could lead to being unable
> to upload packages to fix other bugs.

Doesn't sound like it actually solves the problem that needs solving for the
same reasons as option 2. above, but could be usable if fleshed out
appropriately.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-26-2007, 12:11 PM
Neil Williams
 
Default -Wl,--as-needed considered possibly harmful

On Tue, 2007-12-25 at 20:12 -0800, Steve Langasek wrote:
> On Fri, Dec 21, 2007 at 10:55:32AM +0000, Neil Williams wrote:
> > On Thu, 20 Dec 2007 21:44:19 -0800
> > Steve Langasek <vorlon@debian.org> wrote:

> > > But *nothing* here guarantees that the version of libbar the application is
> > > linked against has the same ABI as the one libfoo itself linked against!
>
> > ... until both the application and libfoo are rebuilt. So the issue
> > here is triggering rebuilds of reverse dependencies of libbar?
>
> No. That doesn't cause previously released binaries to blink out of
> existence.
>
> What's required is to ensure that there's a package rename each time
> libfoo's ABI changes, including when the libfoo ABI change is caused by type
> changes in the underlying lib. This is essentially the general case of the
> c102, c2, c2a, and ldbl transitions that we've been through for compiler
> changes over the past few years; in theory we should be able to accomplish
> these transitions for libraries with fewer reverse-dependencies than
> libstdc++ with significantly less pain, as long as library maintainers are
> forewarned.
>
> But once the package name change is handled, the rebuild of reverse-deps
> follows naturally.

That sounds a lot better than the original idea of incorporating the
entire dependency chain into the package name.

I think I'm doing this already - if libfoo1 implements and exports types
from libbar2 and libbar2 moves to libbar3, I would expect to have to
port libfoo to libbar3 and this would usually cause a SONAME bump in
libfoo.

So could I ask, from an upstream perspective, what kind of changes in
the underlying lib might *not* cause such a port and therefore end up
with libfoo1 still being buildable against libbar3 yet *still* require a
SONAME bump to accommodate the transition?

Have I got these possible scenarios correct:
1. libfoo depends on libbar2 without exporting libbar symbols. libfoo
can migrate to libbar3 with internal code changes and if these do not
require changing any libfoo interfaces, libfoo needs no SONAME bump.
pkgconfig does not export libbar in the libfoo --libs data.

If an application uses libbar and libfoo (for whatever reason), the
ported version of that application that uses libbar3 simply needs to
depend on the version of libfoo that depends on libbar3. In this case,
an automated rebuild of the application could miss this step, causing
breakage, yet forcing a change in the libfoo package name seems
unnecessary (especially if there are other applications that depend on
libfoo but not directly on libbar). Another problem is if the
application ports to libbar3 before libfoo - currently, there is no way
of reliably picking this up except the application maintainer being
particularly careful with the pbuilder logs and noticing that libbar2 is
still being installed during the build as well as libbar3 due to the
indirect dependency on libfoo. Maybe pbuilder could highlight such
incidences? (or even fail the build if it happens)? Maybe sbuild too?
However, this would again raise the spectre of being unable to fix
critical bugs in the application should libfoo be slow to port to
libbar3. Again, it's a balance of risk - problems are *possible* when
the app is linked against libbar3 and indirectly against libbar2 but in
the absence of real bugs, is it worth causing more delays to other bug
fixes?

Does libfoo need to use versioned symbols to cope with this or is it
simply down to those applications that use libfoo and libbar to specify
the right version of libfoo once the application itself has ported to
libbar3? (And wait until libfoo has also migrated?) What methods are
needed to ensure that the application does this? (e.g. if left without
changes, an application directly dependent upon libbar3 and libfoo could
be built for unstable and presumably migrate into testing before the
updated libfoo).
There needs to be some check on the application that compares the
dependency chain as well as the dependency list in the package itself.
lintian cannot do that.

2. libfoo depends on libbar2 and exports some libbar symbols in
libfoo-dev. libfoo can migrate to libbar3 with only internal code
changes because it only exports a portion of the libbar API that has not
actually been changed in the libbar2->libbar3 transition. libfoo needs
to export libbar in the libfoo --libs data. Is a SONAME bump needed in
libfoo even though *none* of the libfoo interfaces have changed? As
upstream for libfoo, I would not normally make a SONAME bump in this
situation. Would it be better to rename the Debian package without
bumping the SONAME, e.g. libfoo1-0->libfoo1-1 ? Wouldn't this cause
unnecessary rebuilds of applications that only depend on libfoo and not
libbar?

3. libfoo depends on libbar2 and needs to make changes to its own
interfaces to cope with the libbar transition or needs to export symbols
from the new libbar API and therefore makes a SONAME bump. No problem
here except ensuring that applications transition to both API's at the
same time. Can be enforced by making libbar-dev conflict with the old
libfoo-dev or making the new libfoo-dev depend on the new libbar-dev
version.

It is only in case 2: that I find confusion and a need for some kind of
Debian-only package name change in libfoo. Is that correct?

Now it may be that for case 2: to happen in real situations, libbar
would actually turn out to be a collection of libraries: libbar-x11.so
and libbar-sql.so. Say the libbar2->3 transition only affects libbar-x11
and it is libbar-x11 that is NEEDED by the application, not libbar-sql:

Old package: libbar-x11.so.2.1.3 libbar-sql.so.2.4.1
New package: libbar-x11.so.3.0.0 libbar-sql.so.2.5.0

A package split in libbar would actually seem to be the better solution,
yes?

Have the libbar source build an extra set of packages:
libbar-x113, libbar-x11-dev, libbar-x11-dbg, libbar-doc
libbar-sql2, libbar-sql-dev, libbar-sql-dbg
libbar-dev as a meta package depending on libbar-sql-dev and
libbar-x11-dev
pkgconfig data for libbar-x11 in bar-x11.pc
pkgconfig data for libbar-sql in bar-sql.pc
Remove bar.pc or fold bar-x11.pc and bar-sql.pc into a new bar.pc to
support those applications that use both. Get the whole thing done in
one spell in NEW.

To cope with this transition, libfoo could simply swap the pkg-config
call from:
pkg-config --libs bar
to
pkg-config --libs bar-sql

No SONAME bump, just bump the version of the libbar-dev dependency (or
preferably replace libbar-dev with libbar-sql-dev).

Would this be sufficiently beneficial that the libbar maintainer would
be considered remiss for not implementing such a split?

> > > If
> > > libfoo linked against libbar1, the pkg-config approach only ensures that
> > > when your application is built against the libbar2 version of libbar-dev,
> > > the resulting binary will depend on both libbar1 and libbar2 (despite not
> > > using any symbols from libbar2). All this does is increase the chances of
> > > segfaults or bad runtime behavior as a result of symbol clobbering.
>
> > Maybe I've got this wrong but there would appear to be a few methods to
> > fix this:
> > 1. Incorporating the libbar SONAME into the libfoo package SONAME - as
> > Simon Richter recommended - this could quickly end up with
> > libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that
> > this would actually help anyone if, for example, libbaz0 migrates to
> > libbaz1 in a way that completely breaks libbar2.
>
> Then either libbar2 becomes libbar3 at the same time, or libbar becomes
> unsupported (and the stack above it has to be ported or else it's not
> releasable), or libbaz needs to support symbol versioning to permit
> coexistence of the two versions in the same address space.

Even if the actual fix for libbar2 is only internal? Say a change in
libbaz meant that the core functionality of libbar fails. As "core
functionality", it would be used by libbar but not exported so libbar
would not export libbaz symbols; there is no need for libbar2 to become
libbar3.

Yet the problem isn't in libbaz either, so why force libbaz to implement
versioned symbols through (apparently) no fault of its own?

To me, this whole problem comes down to the applications, not the shared
libraries or pkgconfig. Problems only arise if one package is linked
directly and indirectly against different versions of the same object.
The problem should be solved at the point at which it arises - in
whichever package ends up with the double linkage. Changing all the
shared libraries names and causing lots more transitions with
unnecessary SONAME bumps seems the wrong approach, IMHO, because we end
up with more transitions, not easier transitions.

Lintian cannot check beyond the confines of the .changes file for one
source package so we need a supplementary check and one place for this
would appear to be all those scripts that build in a chroot.

What about making the version of libbar-dev that depends on libbar3,
conflict with libbar2? The application maintainer would soon discover
the problem because the application dependency on libfoo could not be
satisfied in a pbuilder environment until libfoo updates to libbar3
itself. This gives time for the application maintainer to consider an
interim release of the current (unported) version of the application
dependent on libfoo and libbar2, if it is possible to fix certain bugs
that way, and seek an upgrade of libfoo in the meantime. i.e. leave
pkgconfig out of it entirely.

This has the advantage that none of the applications that only depend on
libfoo (and libbar indirectly) would be affected - it is limited to
those who need both libfoo-dev (which brings in libfoo and libbar2) and
libbar-dev (which brings in libbar3 and complains about libbar2). It can
also be implemented entirely within the one library that is undergoing
the transition: libbar.

It also allows applications that still use libbar2 to coexist with
libbar3 - only when trying to build against libbar3 does it become a
problem.

The biggest problem with that approach is upstream. It complicates
porting the application itself - depending on how many other packages
would be removed by apt when trying to install libbar-dev on a real
system. There would be no point making libgtk+-3.0-dev conflict against
libgtk-2.0-0.

However, I think this is manageable for small transitions and less
common libraries - the very ones that would tend to get missed by the
current methods. Everyone knows when a gtk transition is taking place,
everyone is watching for situations where a package gets linked against
libgtk+2.0.so and libgtk+3.0.so and there is little chance that any
program would work with such duplication.

Maybe a check that can be confined to chroots is needed - a function
within pbuilder that checks the build dependencies being requested and
fails if libbar2 and libbar3 are being installed at the same time during
a build? (The mere fact both are needed in a pbuilder build should be
evidence enough that at least one object in the dependency list is going
to end up linked to both.)

It would seem relatively simple to implement: sort the fully parsed
dependency list before calling 'apt-get' to remove duplicates, strip the
SONAME from the list of dependencies, error if any of the remaining
strings are not unique.

Something like (although probably not needing tmpfiles):
#!/bin/sh -e

LIST="libfoo1 libbar2 libbar3 myprog libfoo1"
rm -f tmpfile
for PKG in $LIST; do
echo $PKG >> tmpfile
done
ULIST=`sort -u < tmpfile`
for PKG in $ULIST; do
PKG=`echo "$PKG" | sed -e 's/[0-9]$//'`
echo $PKG >> tmpfile2
done
ORIG=`grep -c '[a-z]' tmpfile`
SORT=`grep -c '[a-z]' tmpfile2`
if [ $ORIG -ne $SORT ]; then
echo -n "FAIL: "
echo $ULIST | sed -e 's/
//'
exit 1
fi
echo "OK"

gives:
FAIL: libbar2 libbar3 libfoo1 myprog

I'm sure that can be improved to only show the problematic packages.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 12-26-2007, 09:36 PM
Robert Collins
 
Default -Wl,--as-needed considered possibly harmful

On Wed, 2007-12-26 at 13:11 +0000, Neil Williams wrote:
>
> So could I ask, from an upstream perspective, what kind of changes in
> the underlying lib might *not* cause such a port and therefore end up
> with libfoo1 still being buildable against libbar3 yet *still* require
> a
> SONAME bump to accommodate the transition?

bar.h:
typedef unsigned int bar;

foo.h:
typedef struct {
bar a_bar;
} exported_foo_type;

Then this patch to bar.h:
@@ -0,1 +0,1 @@
-typedef unsigned int bar;
+typedef size_t bar;

is enough to cause an ABI break in libfoo, without needing 'porting'
work (though it may well cause print formatting failures on 64
environments and other side effects).

-Rob


--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
 
Old 01-02-2008, 06:17 AM
Steve Langasek
 
Default -Wl,--as-needed considered possibly harmful

On Wed, Dec 26, 2007 at 01:11:40PM +0000, Neil Williams wrote:
> > > ... until both the application and libfoo are rebuilt. So the issue
> > > here is triggering rebuilds of reverse dependencies of libbar?

> > No. That doesn't cause previously released binaries to blink out of
> > existence.

> > What's required is to ensure that there's a package rename each time
> > libfoo's ABI changes, including when the libfoo ABI change is caused by type
> > changes in the underlying lib. This is essentially the general case of the
> > c102, c2, c2a, and ldbl transitions that we've been through for compiler
> > changes over the past few years; in theory we should be able to accomplish
> > these transitions for libraries with fewer reverse-dependencies than
> > libstdc++ with significantly less pain, as long as library maintainers are
> > forewarned.

> > But once the package name change is handled, the rebuild of reverse-deps
> > follows naturally.

> That sounds a lot better than the original idea of incorporating the
> entire dependency chain into the package name.

> I think I'm doing this already - if libfoo1 implements and exports types
> from libbar2 and libbar2 moves to libbar3, I would expect to have to
> port libfoo to libbar3 and this would usually cause a SONAME bump in
> libfoo.

> So could I ask, from an upstream perspective, what kind of changes in
> the underlying lib might *not* cause such a port and therefore end up
> with libfoo1 still being buildable against libbar3 yet *still* require a
> SONAME bump to accommodate the transition?

Succinctly addressed by Robert.

> Have I got these possible scenarios correct:

> 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo
> can migrate to libbar3 with internal code changes and if these do not
> require changing any libfoo interfaces, libfoo needs no SONAME bump.

No, "exporting libbar symbols" is not the right line to draw. The right
line is the one I already identified, namely, "libfoo uses some of libbar's
types in its own exported ABI".

> Does libfoo need to use versioned symbols to cope with this

No, libbar does, as the library which has other libraries for
reverse-dependencies.

> There needs to be some check on the application that compares the
> dependency chain as well as the dependency list in the package itself.
> lintian cannot do that.

Not if libbar uses symbol versioning.

> 2. libfoo depends on libbar2 and exports some libbar symbols in
> libfoo-dev. libfoo can migrate to libbar3 with only internal code
> changes because it only exports a portion of the libbar API that has not
> actually been changed in the libbar2->libbar3 transition. libfoo needs
> to export libbar in the libfoo --libs data. Is a SONAME bump needed in
> libfoo even though *none* of the libfoo interfaces have changed? As
> upstream for libfoo, I would not normally make a SONAME bump in this
> situation. Would it be better to rename the Debian package without
> bumping the SONAME, e.g. libfoo1-0->libfoo1-1 ? Wouldn't this cause
> unnecessary rebuilds of applications that only depend on libfoo and not
> libbar?

If libfoo's exported ABI hasn't changed, then any package name or soname
change is gratuitous and should be avoided.

> 3. libfoo depends on libbar2 and needs to make changes to its own
> interfaces to cope with the libbar transition or needs to export symbols
> from the new libbar API and therefore makes a SONAME bump. No problem
> here except ensuring that applications transition to both API's at the
> same time. Can be enforced by making libbar-dev conflict with the old
> libfoo-dev or making the new libfoo-dev depend on the new libbar-dev
> version.

Requires disruptive name changes to libbar-dev which affect all packages
that build-depend on it, and is therefore again inferior to implementing
symbol versions up front.

> > > Maybe I've got this wrong but there would appear to be a few methods to
> > > fix this:
> > > 1. Incorporating the libbar SONAME into the libfoo package SONAME - as
> > > Simon Richter recommended - this could quickly end up with
> > > libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that
> > > this would actually help anyone if, for example, libbaz0 migrates to
> > > libbaz1 in a way that completely breaks libbar2.

> > Then either libbar2 becomes libbar3 at the same time, or libbar becomes
> > unsupported (and the stack above it has to be ported or else it's not
> > releasable), or libbaz needs to support symbol versioning to permit
> > coexistence of the two versions in the same address space.

> Even if the actual fix for libbar2 is only internal?

Then that would eliminate the first option, leaving only the other two.

> Yet the problem isn't in libbaz either, so why force libbaz to implement
> versioned symbols through (apparently) no fault of its own?

Because *all* libraries which have other libs as reverse-dependencies should
implement symbol versioning, precisely as the shortest path for reliably and
permanently addressing the various issues we're discussing.

It *is* libbaz's fault for having an ABI-breaking change. And based on
history, it is only reasonable to assume all such libraries are guilty, and
demand that they use symbol versioning in anticipation of such future ABI
changes.

> To me, this whole problem comes down to the applications, not the shared
> libraries or pkgconfig. Problems only arise if one package is linked
> directly and indirectly against different versions of the same object.
> The problem should be solved at the point at which it arises - in
> whichever package ends up with the double linkage.

No. You seem to agree that each soname change of a library near the bottom
of the stack should not propagate its way up the stack to affect other
libraries that themselves are not affected by the ABI change, but you again
overlook (or disdain) the impact that this has on partial upgrades if we
don't require those base libraries to use symbol versioning. Neither the
rebuild, nor the installation, of packages against the new version of libbar
is instantaneous.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-02-2008, 10:53 AM
Neil Williams
 
Default -Wl,--as-needed considered possibly harmful

On Tue, 1 Jan 2008 23:17:50 -0800
Steve Langasek <vorlon@debian.org> wrote:

> On Wed, Dec 26, 2007 at 01:11:40PM +0000, Neil Williams wrote:
> > I think I'm doing this already - if libfoo1 implements and exports types
> > from libbar2 and libbar2 moves to libbar3, I would expect to have to
> > port libfoo to libbar3 and this would usually cause a SONAME bump in
> > libfoo.
> > Have I got these possible scenarios correct:
>
> > 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo
> > can migrate to libbar3 with internal code changes and if these do not
> > require changing any libfoo interfaces, libfoo needs no SONAME bump.
>
> No, "exporting libbar symbols" is not the right line to draw. The right
> line is the one I already identified, namely, "libfoo uses some of libbar's
> types in its own exported ABI".

That makes more sense, thank you.

> > Does libfoo need to use versioned symbols to cope with this
>
> No, libbar does, as the library which has other libraries for
> reverse-dependencies.

(codehelp has a light bulb moment of clarity). :-)

> > 2. libfoo depends on libbar2 and exports some libbar symbols in
> > libfoo-dev. libfoo can migrate to libbar3 with only internal code
> > changes because it only exports a portion of the libbar API that has not
> > actually been changed in the libbar2->libbar3 transition. libfoo needs
> > to export libbar in the libfoo --libs data. Is a SONAME bump needed in
> > libfoo even though *none* of the libfoo interfaces have changed? As
> > upstream for libfoo, I would not normally make a SONAME bump in this
> > situation.
>
> If libfoo's exported ABI hasn't changed, then any package name or soname
> change is gratuitous and should be avoided.

Agreed.

> > 3. libfoo depends on libbar2 and needs to make changes to its own
> > interfaces to cope with the libbar transition or needs to export symbols
> > from the new libbar API and therefore makes a SONAME bump. No problem
> > here except ensuring that applications transition to both API's at the
> > same time. Can be enforced by making libbar-dev conflict with the old
> > libfoo-dev or making the new libfoo-dev depend on the new libbar-dev
> > version.
>
> Requires disruptive name changes to libbar-dev which affect all packages
> that build-depend on it, and is therefore again inferior to implementing
> symbol versions up front.

OK.

> Because *all* libraries which have other libs as reverse-dependencies should
> implement symbol versioning, precisely as the shortest path for reliably and
> permanently addressing the various issues we're discussing.
>
> It *is* libbaz's fault for having an ABI-breaking change. And based on
> history, it is only reasonable to assume all such libraries are guilty, and
> demand that they use symbol versioning in anticipation of such future ABI
> changes.

OK, I'm doing this upstream for one of my packages - following threads from:
http://lists.debian.org/debian-mentors/2007/05/msg00387.html
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html

That gave me a basic versioning addition to the library, a diff of
objdump -p shows:
+Version definitions:
+1 0x01 0x06077991 libqof.so.1
+2 0x00 0x0f307023 LIBQOF_0.7.3
+

(I'm not putting the history of the symbols into the file at this stage
- no new symbols are added in the new version so the libqof.ver file is
simply marking all as global. I could add historical data - is there any
benefit in that?)

That's upstream covered, it appears I also need debian/libqof1.symbols
from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done
symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able
to create the necessary data itself? I don't provide a .shlib file of
my own at this stage.

(A SONAME bump is due in this library fairly soon so I want to get
symbol versioning into libqof1 prior to the ABI change.)

> No. You seem to agree that each soname change of a library near the bottom
> of the stack should not propagate its way up the stack to affect other
> libraries that themselves are not affected by the ABI change, but you again
> overlook (or disdain) the impact that this has on partial upgrades if we
> don't require those base libraries to use symbol versioning.

It was an oversight. Sorry.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 01-05-2008, 12:52 AM
Steve Langasek
 
Default -Wl,--as-needed considered possibly harmful

On Wed, Jan 02, 2008 at 11:53:16AM +0000, Neil Williams wrote:
> > Because *all* libraries which have other libs as reverse-dependencies should
> > implement symbol versioning, precisely as the shortest path for reliably and
> > permanently addressing the various issues we're discussing.

> > It *is* libbaz's fault for having an ABI-breaking change. And based on
> > history, it is only reasonable to assume all such libraries are guilty, and
> > demand that they use symbol versioning in anticipation of such future ABI
> > changes.

> OK, I'm doing this upstream for one of my packages - following threads from:
> http://lists.debian.org/debian-mentors/2007/05/msg00387.html
> http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html

> That gave me a basic versioning addition to the library, a diff of
> objdump -p shows:
> +Version definitions:
> +1 0x01 0x06077991 libqof.so.1
> +2 0x00 0x0f307023 LIBQOF_0.7.3
> +

> (I'm not putting the history of the symbols into the file at this stage
> - no new symbols are added in the new version so the libqof.ver file is
> simply marking all as global. I could add historical data - is there any
> benefit in that?)

No, I don't think there's any benefit in adding the historical data after
the fact.

> That's upstream covered, it appears I also need debian/libqof1.symbols
> from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done
> symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able
> to create the necessary data itself? I don't provide a .shlib file of
> my own at this stage.

The symbols files are orthogonal to symbol versioning. Symbols files are
basically "per-function shlibs", which are applicable even to libs that
don't use symbol versioning; their main benefit is for libraries which make
backwards-compatible ABI changes.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org