m...@linux.it (Marco d'Itri) writes: > 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'm not ignoring that, but it is not something I can fix. >> > 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. That isn't clear to me. I'm not convinced incrementing the shared library version is the right response to silence a warning printed by the dynamic linker. >> The reason this becomes problematic is because the warning is printed to >> stdout/stderr. > Yes, it makes the binaries useless on older systems. And the direct cause for that is the dynamic linker warning. >> > 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. Yes, in the binary that is linked to that library. > 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. I'm just looking for ideas on what do here. Are you suggesting that libidn upstream should increment the shared library version to resolve this? >> 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. As far as I could tell with my experiment, the ABI hasn't changed. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
