On Tue, Jul 15, 2014 at 1:18 AM, Aurelien Jarno aure...@debian.org wrote:
On Mon, Jul 14, 2014 at 11:14:42PM -0400, Carlos O'Donell wrote:
On Mon, Jul 14, 2014 at 4:36 PM, Aurelien Jarno aure...@debian.org wrote:
glibc 2.19 has changed the libc ABI on s390, more specifically the
setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle
some cases, but it doesn't work when a jmp_buf variable is embedded
into a structure, as it changes the size of the structure. The result
is that mixing programs or libraries built with 2.18 with ones built
with 2.19 do not work anymore, usually they end up with a segmentation
fault. Some persons from this list have experienced that with perl.
That is not true. This is an over generalization of the problem. You
can use libraries built with 2.18 and 2.19 and they work just fine.
I agree I probably a bit over exaggerated here, but the problem is real,
breakages do happen, and some persons on this mailing list have already
experienced them.
The extent of the problem in correct language is listed here:
https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes
This seems to minimize the problem, listing only perl. In practice we
have seen much more breakages, part of them being due to the change of
the __pthread_unwind_buf_t struct.
That is a change that nobody reported. You're the first to mention it
and that does make it more serious. We have discussed this upstream
and I agree that we need more versioning of the interfaces there to
support the change fully.
We first thought it was limited to a few packages (even if all perl is
already more than that), but as time goes more and more issues are
found. libpng and gauche are also affected, the issue with mono is
also likely due to this ABI change.
That is new information, and it is important for distributions to
relay this information back upstream where the decision for a SO bump
can be made.
I can follow up with a list affected packages, but we are slowly
discovering them one by one, so it might takes time. So far we have:
* Mixing modules/libraries built with pre-2.19 and 2.19 libc
- perl
- libpng
You can never support a mixed-ABI environment with versioning.
You must update all of those packages at once.
The best we could do is warn the user of the incompatibility at
runtime and refuse to load the module via dlopen, or refuse to start
the application at startup.
* Using libc 2.19 without rebuilding anything:
- gauche
- mono
This we believe to be pthread issues.
According to upstream [3], the problem is that Debian doesn't do a mass
rebuild, which is the strategy chosen by Red Hat to handle^Wworkaround
this issue. This means some programs might segfault during the upgrade,
or on partially upgraded systems.
I apologize if you took what I wrote to mean that. I did not mean it
was Debian's problem, but rather that Debian suffered the most because
they don't do rebuilds. The two are orthogonal. You face a situation
that is unique to the framework used to build the distribution.
Please engage upstream to champion a SO name bump for libc for
I think that would be the correct solution. That said as it is not
something trivial and thus not done often, it's an opportunity to push
for more ABI changes if some others are envisaged in the future.
The problems are worse.
I just tried to simulate this on x86-64 and there are serious problems.
In most libraries you can load multiple different copies and it won't conflict.
Here libc.so.6 and libc.so.7 or libc.so.6.1 all conflict in the same
namespace and worse control aspects of the implementation like TLS. It
doesn't work to bump the SONAME.
We would have to implement a coordination framework amongst all the
SONAME bumped libc's for all of the basic functionality that had to
keep working. That would force future libcs to stay compatible
internally with other libcs and that would be very difficult to
maintain.
I am starting to think that a tooling option to fail to load mixed-ABI
objects is the only option, with user rebuilds happening after that.
Now we have to chose a strategy for Debian. I see multiple options:
1) Ignore the issue and just rebuild (binNMU) the packages that seems
affected when we discover them. This means partial upgrades will likely
be broken, and that we might discover some broken packages only after
the jessie release.
2) Rebuild (binNMU) all packages. This means partial upgrades will
likely be broken.
3) Bump the soname of affected packages and rebuild their reverse
dependencies. It is the solution that is currently being implemented for
perl. It clearly won't scale if more broken packages (and even for
libpng) are discovered as it requires a source upload and a transition
handled by the release team. It also means breaking the ABI compatibility
with other distributions.
4) Bump the libc soname to libc.so.6.1 and do a libc
