Bug#538513: hppa NPTL switch - bump minimal libc6 requirements to "libc6 (>= 2.10)"
Hi, please do not forget to bump minimal libc6 requirements to "libc6 (>= 2.10)" in libc6.symbols.hppa similarly as in libc6.symbols.sparc. The hppa NPTL switch is 100% *** backward *** compatible. The pthread static initializers compiled against NPTL will not work against linuxthreads (e)glibc. Bump at least libpthread.so.0 and libthread_db.so.1 or be cautious and bump all libraries. Petr -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
Carlos O'Donell a écrit : > On Wed, Sep 2, 2009 at 10:55 AM, Aurelien Jarno 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 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Wed, Sep 2, 2009 at 10:55 AM, Aurelien Jarno 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 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
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 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Tue, Sep 1, 2009 at 8:03 PM, Mike Frysinger 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
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 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 signature.asc Description: This is a digitally signed message part.
Re: hppa nptl switch
Carlos O'Donell a écrit : > On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Tue, Sep 1, 2009 at 3:55 PM, Carlos O'Donell wrote: > On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Mon, Aug 31, 2009 at 12:46 PM, Frans Pop 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Mon, Aug 31, 2009 at 4:16 AM, 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 " 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
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 " 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 into and . 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
On Wed, Aug 19, 2009 at 8:48 AM, Aurelien Jarno 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-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
