Re: hppa nptl switch
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.
> 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
email.
> 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.
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 [1], [2].
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
applications.
> [1] http://lists.debian.org/debian-hppa/2008/09/msg00019.html
> [2] http://lists.debian.org/debian-hppa/2009/06/msg00063.html
Cheers,
Carlos.
Reply to: