This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reverting the s390 jmp_buf/ucontext_t ABI change


On 08/01/2014 08:50 AM, Dan Horák wrote:
I'm the main person behind Fedora for s390x and I have some objections
regarding this change. We had to cope with the breakage in 2.19 early
this year, it took some time to realize what's wrong and we found a
solution how to make it work. After some rebootstrapping work we have
used the planned mass rebuild to clean everything. Due some nasty gcc
4.9 bugs the rebuild on s390 finishes during these days. And you are
telling we should do it again? Sorry, but it is not possible, there is
only one mass rebuild planned in Fedora per release and now it's also
too late when we are approaching Fedora 21 Alpha deadline.

For the benefit of those reading along: s390 is a secondary architecture in Fedora, which means that its release engineering is decoupled from the primary architectures (which are i386, x86_64, armhfp). However, all builds on secondary architectures exactly reproduce the builds on primary architectures, both in terms of source code and installed build dependencies in the build root. As a result, a mass rebuild on a secondary architecture (with the proper tooling, see below) is only possible if it happens on primary architectures as well.

I wonder if another mass rebuild will be scheduled on the primary architectures to make sure that everything is built with a fixed GCC because PR61801 seems to affect a lot of programs using inline assembly (not just glibc).

> Fortunately I
still have the notes for the rebootstrap, so it can be done again (for
Fedora 22), but not now.

It should be considerably easier if you start with Fedora 20 because the ABIs are fully compatible. In fact, if you revert the koji-shadow database to its Fedora 20 state, and the mass rebuild in primary happens, it should be mostly automatic. You could do the same for the Fedora 22 bring-up, but due to the larger jump in versions, problematic packages with tightly versioned cyclic build dependencies are more likely to break.

This could perform a mass rebuild on s390x for Fedora 21 even without one on primary, but it will result in RPM packages with the same name/epoch/version/release/architecture which implement different ABIs, which is rather undesirable.

--
Florian Weimer / Red Hat Product Security


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]