Re: hppa nptl switch
[Changing debian-bsd to debian-glibc, probably more appropriate to
discuss about the internal glibc code ;-)]
On Tue, Aug 18, 2009 at 09:51:52PM -0400, Carlos O'Donell wrote:
> On Tue, Aug 18, 2009 at 2:06 PM, Petr Salinger<Petr.Salinger@seznam.cz> wrote:
> > Hello,
> Hello Petr!
> > may I ask you for status of hppa nptl switch ?
> The work is going very well.
> The work for the switch is done, but during testing I came across
> usability problems with larger programs. I'm currently debugging this.
> I think I need about a week more for debugging at this point.
Have you also been able to fix the testsuite related issues, although
they might be related to this problem.
> > We (GNU/kFreeBSD ports) need upload of (e)glibc 2.10
> > to add some functions. It looks like upload of (e)glibc 2.10
> > into unstable is currently on hold due to planned hppa nptl switch.
> I can't comment directly on what the glibc team is doing. However, I
> did provide Aurelian Jarno with a set of patches for 2.10, and asked
> him to hold on while I debug the failures. I've CC'd Aurelian in this
It was not true until a few weeks, but it is now clearly the case. The
only known remaining problem with glibc 2.10 is a new problem in the
sparc testsuite, that appeared recently while pulling changes from the
stable branch. This is being worked on currently.
> > Please could you also test, whether planned hppa road
> > really supports partial upgrades as expected ?
> > Attached please find tiny example,
> > it should work under all following combination:
> > libcounter lt-compiled + testcounter lt-compiled + lt-glibc
> This will work fine. All old code, no compatibility issue.
> > libcounter lt-compiled + testcounter lt-compiled + nptl-glibc
> This will work fine. The library and application use old
> > libcounter lt-compiled + testcounter nptl-compiled + nptl-glibc
> Currently unsupported.
> > libcounter nptl-compiled + testcounter lt-compiled + nptl-glibc
> Currently unsupported.
> > libcounter nptl-compiled + testcounter nptl-compiled + nptl-glibc
> Works fine, all new code.
> > Does it really work under all combinations ? These correspond
> > to partial upgrades from etch to squeeze, which have to be supported.
> Interesting, I wasn't aware that this was a requirement of a partial
> upgrade. Thanks for bringing this to my attention. I'll go back and
> have a look at your previous proposal.
Yes this is necessary, especially as the upgrade process contains by
definition a situation of partial upgrade.
> GLIBC does not guarantee this type of compatibility. When upstream
> GLIBC versioned the pthread_cond_t interfaces there were exactly the
> same guarantees that I provide now. All parts of the program must use
> the same ABI.
> How did debian handle the pthread_cond_t changeover in 2.3.2?
> So, every time that upstream breaks ABI, does it cause a serious
> problem for partial upgrades?
> There has never been support for a mixed-ABI, which is what you are asking for.
> > In fact I already expressed some concerns in , .
> You did express some concern that these configurations should work,
> but you never identified that these were specifically important to the
> debian upgrade process.
> > The outcome of this might be anywhere between "we are ready"
> > and "postpone nptl switch to eglibc 2.11".
> > Please tell us the current status of hppa nptl switch.
> "we are almost ready", I'm looking into the problems with more complex
AFAIK, the switch to NPTL is a requirement to fix the numerous issues
observed on the HPPA port, and given the recent mails from the release
team, I don't think it is possible to postpone the switch to glibc
Is it possible to keep glibc 2.10 with linuxthreads for now, and
introduce those change after, possibly abusing the 2.11 symbols? I think
this will be needed anyway if we want to merge those patches back
upstream, as 2.10 has already been released.
Aurelien Jarno GPG: 1024D/F1BCDB73