[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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

> [1] http://lists.debian.org/debian-hppa/2008/09/msg00019.html
> [2] http://lists.debian.org/debian-hppa/2009/06/msg00063.html


Reply to: