On Feb 05, Simon Josefsson <si...@josefsson.org> wrote:

> >> > The problem is that this is not enough to make the built binaries work
> >> > on stable again[1] because upstream gratuitously broke the ABI in 1.13
> >> > by versioning the symbols and now it is too late to revert the change.
> >> The symbols are the same, so the ABI should be both forward and
> >> backwards compatible.  See my discussion about a similar issue in:
> > They are not the same, since the old ones are unversioned.
> Resolving the symbol 'foo' works the same, doesn't it?
Yes, but you keep ignoring my point that the linker prints a warning.

> > I know well that "it's just a warning", but the warning means that
> > distributions now must treat this as an ABI change and binaries built
> > with new new library must depend on it.
> Yes, that is required but it is not due to an ABI change in the library
> as far as I can see.  I believe the issue is with the binary linked to
If binaries compiled with a newer library do not work (and the linker
printing a warning means that they do not work for Debian's purposes)
with an older library then you really changed the ABI.

> The reason this becomes problematic is because the warning is printed to
> stdout/stderr.
Yes, it makes the binaries useless on older systems.

> > Since having programs spewing warnings on startup is bad and will
> > often also break things (think e.g. a daemon run by inetd), for all
> > practical purposes you effectively broke the ABI (and without any
> > benefit even!).
> It is not the library that prints the warning -- it is the dynamic
> linker.  In a way, the ABI that an application expects is broken by the
> dynamic linker, not by the library.
> 
> Maybe we could bring this up with the maintainer of the code that prints
> the warning?
WTF? The linker warning is there for a purpose, because library
maintainers do not try to do what you did and so when a symbol is
suddenly unversioned probably there is a real bug.
It's clear that the libc maintainers will never accept to remove the
warning so I do not understand why you keep trying to shift the blame.

> Sure, but it matters where things are fixed: if the problem is not in
> the library, the fix belongs in the applications.  They need to depend
> on a newer version of the library.
Which means that you changed the ABI, my point.

-- 
ciao,
Marco

Attachment: signature.asc
Description: Digital signature

Reply via email to