hppa nptl switch

[Petr Salinger-3]

Hello,

may I ask you for status of hppa nptl switch ?

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.

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
libcounter lt-compiled + testcounter lt-compiled + nptl-glibc
libcounter lt-compiled + testcounter nptl-compiled + nptl-glibc
libcounter nptl-compiled + testcounter lt-compiled + nptl-glibc
libcounter nptl-compiled + testcounter nptl-compiled + nptl-glibc

lt-compiled means compiled against linuxthreads glibc,
nptl-compiled means compiled against nptl glibc.

Does it really work under all combinations ? These correspond
to partial upgrades from etch to squeeze, which have to be supported.
In fact I already expressed some concerns in [1], [2].

The outcome of this might be anywhere between "we are ready"
and "postpone nptl switch to eglibc 2.11".
BTW, the release of 2.11 is expected in November 2009.

Please tell us the current status of hppa nptl switch.

Petr

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

[Carlos O'Donell-2]

On Tue, Aug 18, 2009 at 2:06 PM, Petr Salinger<Petr.Salinger@...> 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.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

> 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.

The static initializer are (re-)exposed by some headers like
<X11/Xthreads.h>, <directfb/direct/modules.h>.
There is no guarantee that library and applications are compiled
against the same set of (e)glibc headers.

> 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?

I do not know what changed in 2.3.2 in linuxthreads/condvar.c,
there is obviously some padding in pthread_cond_t. As long as the size
of pthread_cond_t remains the same and "bytes" initialized in the new
initializer are the same as "bytes" in the old initializer, it should be OK.
Of course, old initializer might initialize more bytes compared to new
one.

> 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.

I am asking for

* sizeof() have to be the same for old and new structures
* new functions have to cope with old static initializers properly
* pthread_mutex_t.__m_kind have to retain the same offset,
   similarly for other user specifiable attributes in initializers

I would describe it as be-backward-compatible.

> You did express some concern that these configurations should work,
> but you never identified that these were specifically important to the
> debian upgrade process.

To clarify, I am not member of release team, in fact I am not even DD.
AFAIK, it should be possible to start with plain lenny installation,
upgrade some packages to (current) squeeze and all should still work.

Cheers

  Petr


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

[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@...> 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
> email.

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 [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.
>

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
2.11.

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.

Cheers,
Aurelien

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Wed, Aug 19, 2009 at 8:48 AM, Aurelien Jarno<aurelien@...> wrote:
> [Changing debian-bsd to debian-glibc, probably more appropriate to
> discuss about the internal glibc code ;-)]
>> > may I ask you for status of hppa nptl switch ?

Petr, Aurelian,

I spent the last two days rewriting the pthread structure layouts for
hppa's nptl implementation.

Thanks to Petr's insight, I was able to restructure both
pthread_mutex_t, and pthread_rwlock_t to be 100% ABI compatible with
Linuxthreads.

In the case of pthread_cond_t, the structure grew so much, that I had
to use some of the old lock words (non-zero initialized words) for new
fields, and this meant that all of the pthread_cond_* functions will
quickly test and zero pthread_cond_t before use. The new NPTL
PTHREAD_COND_INITIALIZER uses the fast-path in the code, thus as
applications are rebuilt they will run faster.

The prototype patch in testing is here:
http://www.parisc-linux.org/~carlos/2009-08-31-glibc-ports-hppa-nptl.diff

This patch is not the final version, I need to remove the
old_pthread_cond_* functions, and cleanup the pthread_cond_* functions
to use the same version number. At the end of the day I'm not going to
version any of the functions, because technically they will be ABI
compatible. I will however, surround the checking code with some
version checks so it can be removed in the future (or generate a
warning).

Please note that the new code *will* support partial upgrades for
debian, since this is a 100% ABI compatible change.

I will report back over the next few days on the status of testing the
new patch.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

Hi.

> I spent the last two days rewriting the pthread structure layouts for
> hppa's nptl implementation.

It looks very nice and promising now, thanks.

> I was able to restructure both pthread_mutex_t, and pthread_rwlock_t to
> be 100% ABI compatible with Linuxthreads.

Strictly speaking, currently they are not,
they are only 100% backward compatible.
But only step away, they could be 100% compatible.
Just the new NPTL initializers should initilize
the four ones as previously in LT.
In practice it shouldn't be problem at all.
Debian should make sure that binary/library compiled
against NPTL-hppa-glibc will require NPTL-hppa-glibc
by proper Depends: line like "libc6 (>= 2.10)".

> The prototype patch in testing is here:
> http://www.parisc-linux.org/~carlos/2009-08-31-glibc-ports-hppa-nptl.diff

It is not possible to use "#include_next <pthread.h>" in
sysdeps/unix/sysv/linux/hppa/nptl/pthread.h, as this file
is installed in libc6-dev for general use.
The proper way would be to convince Mr. Drepper to split
<pthread.h> into <pthread.h> and <bits/pthreadinit.h>.
Good luck with it.

The pthread_cond_init.c should call cond_compat_clear()
instead of cond_compat_check_and_clear() or may be just
"cond->__data.__initializer = 0"

Thanks for all your work.

Petr


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Mon, Aug 31, 2009 at 4:16 AM, Petr Salinger<Petr.Salinger@...> wrote:

> Hi.
>
>> I spent the last two days rewriting the pthread structure layouts for
>> hppa's nptl implementation.
>
> It looks very nice and promising now, thanks.
>
>> I was able to restructure both pthread_mutex_t, and pthread_rwlock_t to be
>> 100% ABI compatible with Linuxthreads.
>
> Strictly speaking, currently they are not,
> they are only 100% backward compatible.
> But only step away, they could be 100% compatible.
> Just the new NPTL initializers should initilize
> the four ones as previously in LT.

Yes, my intent was to do exactly that, I had not yet fixed pthread.h
to set the old lock words to all one. I have done exactly this in the
most recent version of my patch. The pthread_mutex_t and
pthread_rwlock_t are now 100% ABI compatible with Linuxthreads.

> In practice it shouldn't be problem at all.
> Debian should make sure that binary/library compiled
> against NPTL-hppa-glibc will require NPTL-hppa-glibc
> by proper Depends: line like "libc6 (>= 2.10)".

Does every package have to do this? I'm not very familiar with all the
packaging requirements.

>> The prototype patch in testing is here:
>> http://www.parisc-linux.org/~carlos/2009-08-31-glibc-ports-hppa-nptl.diff

Second version here:
http://www.parisc-linux.org/~carlos/2009-08-31-glibc-ports-hppa-nptl-v2.diff

The next version is currently testing. It still does not include code
to remove cond_*_clear calls when the ABI level is raised to 2.10.

> It is not possible to use "#include_next <pthread.h>" in
> sysdeps/unix/sysv/linux/hppa/nptl/pthread.h, as this file
> is installed in libc6-dev for general use.

Fixed.

> The pthread_cond_init.c should call cond_compat_clear()
> instead of cond_compat_check_and_clear() or may be just
> "cond->__data.__initializer = 0"

Fixed.

Thanks for the review.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

Carlos O'Donell wrote:
>> In practice it shouldn't be problem at all.
>> Debian should make sure that binary/library compiled
>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>> by proper Depends: line like "libc6 (>= 2.10)".
>
> Does every package have to do this? I'm not very familiar with all the
> packaging requirements.

It is something that should automatically get done correctly as long as
the libc-dev package defines the minimum version that way.

The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
Currently this has lines like:
   libc 6 libc6 (>= 2.9)

It's virtually certain that the shlibs file will be updated to read
'(>= 2.10)' when the glibc maintainers switch to that version.

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Mon, Aug 31, 2009 at 12:46 PM, Frans Pop<elendil@...> wrote:

> Carlos O'Donell wrote:
>>> In practice it shouldn't be problem at all.
>>> Debian should make sure that binary/library compiled
>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>>> by proper Depends: line like "libc6 (>= 2.10)".
>>
>> Does every package have to do this? I'm not very familiar with all the
>> packaging requirements.
>
> It is something that should automatically get done correctly as long as
> the libc-dev package defines the minimum version that way.
>
> The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
> Currently this has lines like:
>   libc 6 libc6 (>= 2.9)
>
> It's virtually certain that the shlibs file will be updated to read
> '(>= 2.10)' when the glibc maintainers switch to that version.

Thanks Frans. This is what I expected.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Frans Pop a écrit :

> Carlos O'Donell wrote:
>>> In practice it shouldn't be problem at all.
>>> Debian should make sure that binary/library compiled
>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>>> by proper Depends: line like "libc6 (>= 2.10)".
>> Does every package have to do this? I'm not very familiar with all the
>> packaging requirements.
>
> It is something that should automatically get done correctly as long as
> the libc-dev package defines the minimum version that way.
>
> The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
> Currently this has lines like:
>    libc 6 libc6 (>= 2.9)
>

No, as glibc uses symbols files, this file is actually not used.
Nevertheless it is still possible to resolve all symbols to libc6 (>= 2.10).

--
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno<aurelien@...> wrote:

> Frans Pop a écrit :
>> Carlos O'Donell wrote:
>>>> In practice it shouldn't be problem at all.
>>>> Debian should make sure that binary/library compiled
>>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>>>> by proper Depends: line like "libc6 (>= 2.10)".
>>> Does every package have to do this? I'm not very familiar with all the
>>> packaging requirements.
>>
>> It is something that should automatically get done correctly as long as
>> the libc-dev package defines the minimum version that way.
>>
>> The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
>> Currently this has lines like:
>>    libc 6 libc6 (>= 2.9)
>>
>
> No, as glibc uses symbols files, this file is actually not used.
> Nevertheless it is still possible to resolve all symbols to libc6 (>= 2.10).

Once an application is rebuilt against a new libc, what prevents the
user from downgrading libc and breaking the application?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thibaut VARENE-2]

On Tue, Sep 1, 2009 at 3:55 PM, Carlos O'Donell<carlos@...> wrote:

> On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno<aurelien@...> wrote:
>> Frans Pop a écrit :
>>> Carlos O'Donell wrote:
>>>>> In practice it shouldn't be problem at all.
>>>>> Debian should make sure that binary/library compiled
>>>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>>>>> by proper Depends: line like "libc6 (>= 2.10)".
>>>> Does every package have to do this? I'm not very familiar with all the
>>>> packaging requirements.
>>>
>>> It is something that should automatically get done correctly as long as
>>> the libc-dev package defines the minimum version that way.
>>>
>>> The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
>>> Currently this has lines like:
>>>    libc 6 libc6 (>= 2.9)
>>>
>>
>> No, as glibc uses symbols files, this file is actually not used.
>> Nevertheless it is still possible to resolve all symbols to libc6 (>= 2.10).
>
> Once an application is rebuilt against a new libc, what prevents the
> user from downgrading libc and breaking the application?

I'd say "common sense" but I recall we don't have protection against
silliness ;^)

T-Bone

--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Carlos O'Donell a écrit :

> On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno<aurelien@...> wrote:
>> Frans Pop a écrit :
>>> Carlos O'Donell wrote:
>>>>> In practice it shouldn't be problem at all.
>>>>> Debian should make sure that binary/library compiled
>>>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
>>>>> by proper Depends: line like "libc6 (>= 2.10)".
>>>> Does every package have to do this? I'm not very familiar with all the
>>>> packaging requirements.
>>> It is something that should automatically get done correctly as long as
>>> the libc-dev package defines the minimum version that way.
>>>
>>> The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs.
>>> Currently this has lines like:
>>>    libc 6 libc6 (>= 2.9)
>>>
>> No, as glibc uses symbols files, this file is actually not used.
>> Nevertheless it is still possible to resolve all symbols to libc6 (>= 2.10).
>
> Once an application is rebuilt against a new libc, what prevents the
> user from downgrading libc and breaking the application?
>

If we make sure that the new programs are using symbols from version
GLIBC_2.10, the program should refuse to start with a lower version of
the glibc.

--
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Frysinger]

On Tuesday 01 September 2009 11:50:27 Aurelien Jarno wrote:
> Carlos O'Donell a écrit :
> > On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno<aurelien@...>
wrote:

> >> Frans Pop a écrit :
> >>> Carlos O'Donell wrote:
> >>>>> In practice it shouldn't be problem at all.
> >>>>> Debian should make sure that binary/library compiled
> >>>>> against NPTL-hppa-glibc will require NPTL-hppa-glibc
> >>>>> by proper Depends: line like "libc6 (>= 2.10)".
> >>>>
> >>>> Does every package have to do this? I'm not very familiar with all the
> >>>> packaging requirements.
> >>>
> >>> It is something that should automatically get done correctly as long as
> >>> the libc-dev package defines the minimum version that way.
> >>>
> >>> The mechanism that determines this is in
> >>> /var/lib/dpkg/info/libc6.shlibs. Currently this has lines like:
> >>>    libc 6 libc6 (>= 2.9)
> >>
> >> No, as glibc uses symbols files, this file is actually not used.
> >> Nevertheless it is still possible to resolve all symbols to libc6 (>=
> >> 2.10).
> >
> > Once an application is rebuilt against a new libc, what prevents the
> > user from downgrading libc and breaking the application?
>
> If we make sure that the new programs are using symbols from version
> GLIBC_2.10, the program should refuse to start with a lower version of
> the glibc.

i think the question was one about packaging rather than general use ?  if you
build a package against a newer glibc version but it only uses older symbols,
then in theory it should work fine with older glibc versions.  if the symbol
changes between versions, then it should have corresponding symbol version
changes as well (which will automatically be recorded in the binary).
-mike

[Carlos O'Donell-2]

On Tue, Sep 1, 2009 at 8:03 PM, Mike Frysinger<vapier@...> wrote:
> i think the question was one about packaging rather than general use ?  if you
> build a package against a newer glibc version but it only uses older symbols,
> then in theory it should work fine with older glibc versions.  if the symbol
> changes between versions, then it should have corresponding symbol version
> changes as well (which will automatically be recorded in the binary).

Yes, the question is specifically about packaging.

If the answer is "Debian does not prevent you from downgrading glibc,
even if you have new packages built against the new glibc", then I
accept that.

However, I have another question. What prevents applications built on
a buildd against a newer glibc, from being installed on a system with
an older glibc? Glibc provides backwards compatibility, but *not*
forwards. What happens in the packaging subsystem to prevent this?

How does an application encode "I was built against glibc X.Y,
therefore I should only be run on such a glibc or newer."

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Wed, Sep 02, 2009 at 10:09:22AM -0400, Carlos O'Donell wrote:

> On Tue, Sep 1, 2009 at 8:03 PM, Mike Frysinger<vapier@...> wrote:
> > i think the question was one about packaging rather than general use ?  if you
> > build a package against a newer glibc version but it only uses older symbols,
> > then in theory it should work fine with older glibc versions.  if the symbol
> > changes between versions, then it should have corresponding symbol version
> > changes as well (which will automatically be recorded in the binary).
>
> Yes, the question is specifically about packaging.
>
> If the answer is "Debian does not prevent you from downgrading glibc,
> even if you have new packages built against the new glibc", then I
> accept that.
>

With the correct shlibs and symbol files, all packages built against the
new glibc will depends on libc6 (>= 2.10). This way it won't be possible
to downgrade the libc6 packages is packages compiled against the new
glibc are installed.

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Wed, Sep 2, 2009 at 10:55 AM, Aurelien Jarno<aurelien@...> wrote:

> On Wed, Sep 02, 2009 at 10:09:22AM -0400, Carlos O'Donell wrote:
>> On Tue, Sep 1, 2009 at 8:03 PM, Mike Frysinger<vapier@...> wrote:
>> > i think the question was one about packaging rather than general use ?  if you
>> > build a package against a newer glibc version but it only uses older symbols,
>> > then in theory it should work fine with older glibc versions.  if the symbol
>> > changes between versions, then it should have corresponding symbol version
>> > changes as well (which will automatically be recorded in the binary).
>>
>> Yes, the question is specifically about packaging.
>>
>> If the answer is "Debian does not prevent you from downgrading glibc,
>> even if you have new packages built against the new glibc", then I
>> accept that.
>>
>
> With the correct shlibs and symbol files, all packages built against the
> new glibc will depends on libc6 (>= 2.10). This way it won't be possible
> to downgrade the libc6 packages is packages compiled against the new
> glibc are installed.

Is the shlibs sufficient? For example, data structures aren't
versioned. In my new NPTL patches, I change PTHREAD_COND_INITIALIZER,
but I do not version anything (not required because the current
functions support both old and new style initializers), therefore the
symbol files will be identical?

Thanks a lot for your help in answering my debian related packaging questions.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Carlos O'Donell a écrit :

> On Wed, Sep 2, 2009 at 10:55 AM, Aurelien Jarno<aurelien@...> wrote:
>> On Wed, Sep 02, 2009 at 10:09:22AM -0400, Carlos O'Donell wrote:
>>> On Tue, Sep 1, 2009 at 8:03 PM, Mike Frysinger<vapier@...> wrote:
>>>> i think the question was one about packaging rather than general use ?  if you
>>>> build a package against a newer glibc version but it only uses older symbols,
>>>> then in theory it should work fine with older glibc versions.  if the symbol
>>>> changes between versions, then it should have corresponding symbol version
>>>> changes as well (which will automatically be recorded in the binary).
>>> Yes, the question is specifically about packaging.
>>>
>>> If the answer is "Debian does not prevent you from downgrading glibc,
>>> even if you have new packages built against the new glibc", then I
>>> accept that.
>>>
>> With the correct shlibs and symbol files, all packages built against the
>> new glibc will depends on libc6 (>= 2.10). This way it won't be possible
>> to downgrade the libc6 packages is packages compiled against the new
>> glibc are installed.
>
> Is the shlibs sufficient? For example, data structures aren't
> versioned. In my new NPTL patches, I change PTHREAD_COND_INITIALIZER,
> but I do not version anything (not required because the current
> functions support both old and new style initializers), therefore the
> symbol files will be identical?
>

Yes, but we can change the symbol files so that all versions of all
symbols (for current symbols) resolve to libc6 (>= 2.10). This has
already been done for example for the sparc v8 to sparc v8plus ABI change.

--
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...