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
signature.asc
Description: Digital signature