Ubuntu
glibc package

libc6-dev: totally incoherent pthread related includes files for dynamic linking

Bug #9860 reported by Debian Bug Importer
8
Affects Status Importance Assigned to Milestone
glibc (Debian)
Fix Released
Unknown
glibc (Ubuntu)
Fix Released
Wishlist
Jeff Bailey

Bug Description

Automatically imported from Debian bug report #279423 http://bugs.debian.org/279423

See original description
Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #279423 http://bugs.debian.org/279423

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <E1CP7fZ-0001E9-00@localhost>
Date: Wed, 03 Nov 2004 00:02:29 +0100
From: Eric Valette <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libc6-dev: totally incoherent pthread related includes files for dynamic
 linking

Package: libc6-dev
Version: 2.3.2.ds1-18
Severity: grave

Due implementaion decisions made to have NPTL threads availiable when
possible, the actual status of libc6-dev is almost incoherent :
 1) The includes related to pthread (pthread.h, semaphores.h, bits/*.h)
 are the one that belong to linuxThread includes not nptl ones,
 2) When linking in dynamic mode, nptl implementation is dynamically
 chosen while the includes that have been used to compile the program
 arethe linuxThread ones,
 3) When linking in static mode, linuxThread implementation is chosen
 and not NPTL one (wonder why on i386 and PPC at least),
 4) There is no way to get NPTL threading using static linking mode.
 This makes programme behaves differently when using static and
 dynamic linking,

To clean up the mess, I think that :

 1) When possible, the same thread implementation should be chosen
 in dynamic and static mode. Most distrib indeed provide a nptl-dev
 package for dynamic and static nptl thread usage,
 2) As default linking is dynamic, default includes should be the
 NPTL ones and not the linuxThreads ones,
 3) If someone find a reason to not use NPTL in static mode, then
 a diffrent package for static linuxThread code should be availiable

I would also like to recall that static linking when optimal/soft RT
performance are required is something still very usefull as mlockall and
dynamic libraries do waste so much physical memory (e.g 70 Mb VmSize vs 10 Mb).

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-rc1-bk6
Locale: LANG=en_IE@euro, LC_CTYPE=en_IE (charmap=ISO-8859-15) (ignored: LC_ALL set to en_IE@euro)

Versions of packages libc6-dev depends on:
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme

-- no debconf information

Revision history for this message
In , Colin Watson (cjwatson) wrote : not release-critical

# This bug does not render the package unusable.
severity 279423 important
thanks

--
Colin Watson [<email address hidden>]

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 2 Nov 2004 23:52:10 +0000
From: Colin Watson <email address hidden>
To: <email address hidden>
Subject: not release-critical

# This bug does not render the package unusable.
severity 279423 important
thanks

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Daniel Jacobowitz (dan) wrote : Re: Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking

On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote:
> 2) When linking in dynamic mode, nptl implementation is dynamically
> chosen while the includes that have been used to compile the program
> arethe linuxThread ones,

This is only true if your kernel supports NPTL.

> 1) When possible, the same thread implementation should be chosen
> in dynamic and static mode. Most distrib indeed provide a nptl-dev
> package for dynamic and static nptl thread usage,

nptl-dev provides headers and static libraries for NPTL, which we don't
provide at all. In fact most distributions do exactly the same as
Debian with their default headers and dynamic libraries.

> 2) As default linking is dynamic, default includes should be the
> NPTL ones and not the linuxThreads ones,

This does not work correctly because the static linker (i.e. GNU ld)
does not search the hwcap directories. It thinks the default libraries
being linked to are the LinuxThreads ones. That's why we provide
LinuxThreads headers.

> 3) If someone find a reason to not use NPTL in static mode, then
> a diffrent package for static linuxThread code should be availiable

Like, the bulk of deployed Linux systems which can't run NPTL
applications?

We can revisit these choices after sarge.

> I would also like to recall that static linking when optimal/soft RT
> performance are required is something still very usefull as mlockall and
> dynamic libraries do waste so much physical memory (e.g 70 Mb VmSize vs 10 Mb).

If you only have one application that matters, and thousands of shared
libraries, maybe. Using mlockall to keep a shared libc.so in memory
takes 1.3MB.

--
Daniel Jacobowitz

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 3 Nov 2004 12:28:45 -0500
From: Daniel Jacobowitz <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic
 linking

On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote:
> 2) When linking in dynamic mode, nptl implementation is dynamically
> chosen while the includes that have been used to compile the program
> arethe linuxThread ones,

This is only true if your kernel supports NPTL.

> 1) When possible, the same thread implementation should be chosen
> in dynamic and static mode. Most distrib indeed provide a nptl-dev
> package for dynamic and static nptl thread usage,

nptl-dev provides headers and static libraries for NPTL, which we don't
provide at all. In fact most distributions do exactly the same as
Debian with their default headers and dynamic libraries.

> 2) As default linking is dynamic, default includes should be the
> NPTL ones and not the linuxThreads ones,

This does not work correctly because the static linker (i.e. GNU ld)
does not search the hwcap directories. It thinks the default libraries
being linked to are the LinuxThreads ones. That's why we provide
LinuxThreads headers.

> 3) If someone find a reason to not use NPTL in static mode, then
> a diffrent package for static linuxThread code should be availiable

Like, the bulk of deployed Linux systems which can't run NPTL
applications?

We can revisit these choices after sarge.

> I would also like to recall that static linking when optimal/soft RT
> performance are required is something still very usefull as mlockall and
> dynamic libraries do waste so much physical memory (e.g 70 Mb VmSize vs 10 Mb).

If you only have one application that matters, and thousands of shared
libraries, maybe. Using mlockall to keep a shared libc.so in memory
takes 1.3MB.

--
Daniel Jacobowitz

Revision history for this message
In , EricV (eric-valette) wrote :
Download full text (4.0 KiB)

Daniel Jacobowitz wrote:
> On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote:
>
>> 2) When linking in dynamic mode, nptl implementation is dynamically
>> chosen while the includes that have been used to compile the program
>> arethe linuxThread ones,
>
>
> This is only true if your kernel supports NPTL.

Any 2.6 kernel supports them and 2.6 being the _current_ stable branch
isn't it... I guess sarge will come with an optionnal 2.6.x x>=8. Would
you bet that more than 80% of the users will chose a 2.6 kernel if they
know they can use it... Or will sarge be already obsolete when it will
endly comes out? (glic in other distribs is already 2.3.3 + cvs 2.3.4)

> nptl-dev provides headers and static libraries for NPTL, which we don't
> provide at all.

This is a problem because benchmarks and POSIX compatibility tests have
already proven that NPTL ptread implementation is far superior to
Linuxthread one, besides being still actively developped...

> In fact most distributions do exactly the same as
> Debian with their default headers and dynamic libraries.

So because other distrib mades bad choices, Debian must follow. Good
point. I will check and report if this is even true latter on. Anyway,
you will not argue that using linuxThread's pthread.h and semaphore.h
for compiling nptl pthread programs is a good choice? Are you? I made a
simple test that consist in taking the debian patched glibc-2.3.2,
compile it with enable-add-ons=nptl and --prefix=/usr/local/nptlstatic
And the checked what includes are installed, its the NPTL ones not the
linuxthread ones. So the bug comes from debian not from original glibc...

If you have compatibility problem, then provide libc6-linuxthread and
libc6-nptl and their respective -dev. libc6-nptl pre-install can easilly
check that uname -r reports > 2.6.0 and refuse to install.

>> 2) As default linking is dynamic, default includes should be the
>> NPTL ones and not the linuxThreads ones,
>
>
> This does not work correctly because the static linker (i.e. GNU ld)
> does not search the hwcap directories. It thinks the default libraries
> being linked to are the LinuxThreads ones. That's why we provide
> LinuxThreads headers.

Someone made nasty things to enable the dynamic linker to dynamically
choose between NPTL vs linuxThread implementation and now you use it for
justifying the actual mess? Another good point!
The point is that on a 2.6 kernel, with dynamic linking, NPTL library is
used, and linuxThread include are used by gcc to compile the program and
that glibc code is not expecting this.

>> 3) If someone find a reason to not use NPTL in static mode, then
>> a diffrent package for static linuxThread code should be availiable
>
>
> Like, the bulk of deployed Linux systems which can't run NPTL
> applications?

I do not care so much about deployed systems :
 - If they did not compile the software themselves then they have no
problem,
 - if they did compile it, after upgrade, it is likely to not even load
due to incorrect dynamic library version. And they will need to
recompile anyway. If they recompile the problem will go away,

> We can revisit these choices after ...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (4.3 KiB)

Message-ID: <email address hidden>
Date: Wed, 03 Nov 2004 21:45:51 +0100
From: Eric Valette <email address hidden>
To: Daniel Jacobowitz <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

Daniel Jacobowitz wrote:
> On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote:
>
>> 2) When linking in dynamic mode, nptl implementation is dynamically
>> chosen while the includes that have been used to compile the program
>> arethe linuxThread ones,
>
>
> This is only true if your kernel supports NPTL.

Any 2.6 kernel supports them and 2.6 being the _current_ stable branch
isn't it... I guess sarge will come with an optionnal 2.6.x x>=8. Would
you bet that more than 80% of the users will chose a 2.6 kernel if they
know they can use it... Or will sarge be already obsolete when it will
endly comes out? (glic in other distribs is already 2.3.3 + cvs 2.3.4)

> nptl-dev provides headers and static libraries for NPTL, which we don't
> provide at all.

This is a problem because benchmarks and POSIX compatibility tests have
already proven that NPTL ptread implementation is far superior to
Linuxthread one, besides being still actively developped...

> In fact most distributions do exactly the same as
> Debian with their default headers and dynamic libraries.

So because other distrib mades bad choices, Debian must follow. Good
point. I will check and report if this is even true latter on. Anyway,
you will not argue that using linuxThread's pthread.h and semaphore.h
for compiling nptl pthread programs is a good choice? Are you? I made a
simple test that consist in taking the debian patched glibc-2.3.2,
compile it with enable-add-ons=nptl and --prefix=/usr/local/nptlstatic
And the checked what includes are installed, its the NPTL ones not the
linuxthread ones. So the bug comes from debian not from original glibc...

If you have compatibility problem, then provide libc6-linuxthread and
libc6-nptl and their respective -dev. libc6-nptl pre-install can easilly
check that uname -r reports > 2.6.0 and refuse to install.

>> 2) As default linking is dynamic, default includes should be the
>> NPTL ones and not the linuxThreads ones,
>
>
> This does not work correctly because the static linker (i.e. GNU ld)
> does not search the hwcap directories. It thinks the default libraries
> being linked to are the LinuxThreads ones. That's why we provide
> LinuxThreads headers.

Someone made nasty things to enable the dynamic linker to dynamically
choose between NPTL vs linuxThread implementation and now you use it for
justifying the actual mess? Another good point!
The point is that on a 2.6 kernel, with dynamic linking, NPTL library is
used, and linuxThread include are used by gcc to compile the program and
that glibc code is not expecting this.

>> 3) If someone find a reason to not use NPTL in static mode, then
>> a diffrent package for static linuxThread code should be availiable
>
>
> Like, the bulk of deployed Linux systems which can't run NPTL
> applications?

I do not care so much about deployed systems :
 - If they did not compile t...

Read more...

Revision history for this message
In , EricV (eric-valette) wrote :

Eric Valette wrote:

>> In fact most distributions do exactly the same as
>> Debian with their default headers and dynamic libraries.
>
>
> So because other distrib mades bad choices, Debian must follow. Good
> point. I will check and report if this is even true latter on.

That is not even true :
 1)
<http://www.suse.com/en/private/products/suse_linux/prof/packages_professional/glibc-devel.html>

Suze provides both threading in in glibc-devel with I think is coherent.

 2) Fedora does the same £%µ than debian

 3) Mandrake provide a nptl-devel.

So no, your statement is not even true and again, it is not because
other distrib make questionnable decision that you should follow...

-- eric

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 03 Nov 2004 23:03:53 +0100
From: Eric Valette <email address hidden>
To: <email address hidden>
Cc: Daniel Jacobowitz <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

Eric Valette wrote:

>> In fact most distributions do exactly the same as
>> Debian with their default headers and dynamic libraries.
>=20
>=20
> So because other distrib mades bad choices, Debian must follow. Good=20
> point. I will check and report if this is even true latter on.=20

That is not even true :
 1)=20
<http://www.suse.com/en/private/products/suse_linux/prof/packages_profess=
ional/glibc-devel.html>

Suze provides both threading in in glibc-devel with I think is coherent.

 2) Fedora does the same =A3%=B5 than debian

 3) Mandrake provide a nptl-devel.

So no, your statement is not even true and again, it is not because=20
other distrib make questionnable decision that you should follow...

-- eric

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote :

severity 279423 wishlist
retitle 279423 libc6-dev: libc6-dev should ship /usr/include/nptl
merge 279423 276062
thanks

At Wed, 03 Nov 2004 23:03:53 +0100,
Eric Valette wrote:
> Eric Valette wrote:
>
> >> In fact most distributions do exactly the same as
> >> Debian with their default headers and dynamic libraries.
> >
> >
> > So because other distrib mades bad choices, Debian must follow. Good
> > point. I will check and report if this is even true latter on.
>
> That is not even true :
> 1)
> <http://www.suse.com/en/private/products/suse_linux/prof/packages_professional/glibc-devel.html>
>
> Suze provides both threading in in glibc-devel with I think is coherent.
>
> 2) Fedora does the same �%� than debian
>
> 3) Mandrake provide a nptl-devel.

OK, we will ship /usr/include/nptl in future, like
/usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
and changed title, and merged with #276062. If you have another
comments, please let us know.

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 18:46:19 +0900
From: GOTO Masanori <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: Daniel Jacobowitz <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic
 linking

severity 279423 wishlist
retitle 279423 libc6-dev: libc6-dev should ship /usr/include/nptl
merge 279423 276062
thanks

At Wed, 03 Nov 2004 23:03:53 +0100,
Eric Valette wrote:
> Eric Valette wrote:
>=20
> >> In fact most distributions do exactly the same as
> >> Debian with their default headers and dynamic libraries.
> >=20
> >=20
> > So because other distrib mades bad choices, Debian must follow. Good=20
> > point. I will check and report if this is even true latter on.=20
>=20
> That is not even true :
> 1)=20
> <http://www.suse.com/en/private/products/suse_linux/prof/packages_profess=
 ional/glibc-devel.html>
>=20
> Suze provides both threading in in glibc-devel with I think is coherent.
>=20
> 2) Fedora does the same =EF=BF=BD%=EF=BF=BD than debian
>=20
> 3) Mandrake provide a nptl-devel.

OK, we will ship /usr/include/nptl in future, like
/usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
and changed title, and merged with #276062. If you have another
comments, please let us know.

Regards,
-- gotom

Revision history for this message
In , EricV (eric-valette) wrote :

GOTO Masanori wrote:
> severity 279423 wishlist
> retitle 279423 libc6-dev: libc6-dev should ship /usr/include/nptl
> merge 279423 276062
> thanks
>
> At Wed, 03 Nov 2004 23:03:53 +0100,
> Eric Valette wrote:
>
>>Eric Valette wrote:
>>
>>
>>>>In fact most distributions do exactly the same as
>>>>Debian with their default headers and dynamic libraries.
>>>
>>>
>>>So because other distrib mades bad choices, Debian must follow. Good
>>>point. I will check and report if this is even true latter on.
>>
>>That is not even true :
>> 1)
>><http://www.suse.com/en/private/products/suse_linux/prof/packages_professional/glibc-devel.html>
>>
>>Suze provides both threading in in glibc-devel with I think is coherent.
>>
>> 2) Fedora does the same �%� than debian
>>
>> 3) Mandrake provide a nptl-devel.
>
>
> OK, we will ship /usr/include/nptl in future, like
> /usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
> and changed title, and merged with #276062. If you have another
> comments, please let us know.
>
> Regards,
> -- gotom

I beg to disagree : it is a clear bug to compile with linuxthread
includes when running NPTL threads. Not a whislist.

Doing this you are behaving like a child saying everything I do is
perfect. Come on, grow up... And by the way, the debian patched glibc
does not seem to work with ntpl static...

A whishlist would be please upgrade to glibc 2.3.3 because your libc is
so old...

--
    __
   / ` Eric Valette
  /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 13:34:27 +0100
From: Eric Valette <email address hidden>
To: GOTO Masanori <email address hidden>
Cc: <email address hidden>, Daniel Jacobowitz <email address hidden>,
 <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

GOTO Masanori wrote:
> severity 279423 wishlist
> retitle 279423 libc6-dev: libc6-dev should ship /usr/include/nptl
> merge 279423 276062
> thanks
>=20
> At Wed, 03 Nov 2004 23:03:53 +0100,
> Eric Valette wrote:
>=20
>>Eric Valette wrote:
>>
>>
>>>>In fact most distributions do exactly the same as
>>>>Debian with their default headers and dynamic libraries.
>>>
>>>
>>>So because other distrib mades bad choices, Debian must follow. Good=20
>>>point. I will check and report if this is even true latter on.=20
>>
>>That is not even true :
>> 1)=20
>><http://www.suse.com/en/private/products/suse_linux/prof/packages_profe=
 ssional/glibc-devel.html>
>>
>>Suze provides both threading in in glibc-devel with I think is coherent=
 =2E
>>
>> 2) Fedora does the same =EF=BF=BD%=EF=BF=BD than debian
>>
>> 3) Mandrake provide a nptl-devel.
>=20
>=20
> OK, we will ship /usr/include/nptl in future, like
> /usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
> and changed title, and merged with #276062. If you have another
> comments, please let us know.
>=20
> Regards,
> -- gotom

I beg to disagree : it is a clear bug to compile with linuxthread=20
includes when running NPTL threads. Not a whislist.

Doing this you are behaving like a child saying everything I do is=20
perfect. Come on, grow up... And by the way, the debian patched glibc=20
does not seem to work with ntpl static...

A whishlist would be please upgrade to glibc 2.3.3 because your libc is=20
so old...

--=20
    __
   / ` Eric Valette
  /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote :

At Sat, 06 Nov 2004 13:34:27 +0100,
Eric Valette wrote:
> > OK, we will ship /usr/include/nptl in future, like
> > /usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
> > and changed title, and merged with #276062. If you have another
> > comments, please let us know.
> >
> > Regards,
> > -- gotom
>
> I beg to disagree : it is a clear bug to compile with linuxthread
> includes when running NPTL threads. Not a whislist.
>
> Doing this you are behaving like a child saying everything I do is
> perfect. Come on, grow up... And by the way, the debian patched glibc
> does not seem to work with ntpl static...

Yes, I think you're correct. I didn't deny your opinion. So I tagged
it as wishlist for working future glibc package after sarge. It's not
"closing bug". I have tagged for glibc packages as long as I can,
because we have over 400 bugs - it's important to classify which bugs
are user-requested matter, and which bugs are actual glibc code fault.
We're effort to fix bugs (I closed over dozens of bugs in this year),
but everyday we're getting another bugs (and half of bugs are not
glibc related).

It's worthwhile including nptl things. If you want to include it,
it's nice to send your patches. Note that I'm feel so not pleasure,
because we're _not_ your subcontractor for your job.

> A whishlist would be please upgrade to glibc 2.3.3 because your libc is
> so old...

Eric, please calm down.

You need to educate the current status of glibc package. The current
status is "base-freeze". Even if we update it, release managers
decide to drop that package from sarge (and that decision is quite
correct). If you don't read debian-glibc lists, read and search my
opinion. I have been waiting to update glibc over _one year_. I'm
preparing glibc-snapshot package in experimental, so once it's
included in experimental, you can put your patch easily.

Regards,
-- gotom

Revision history for this message
In , EricV (eric-valette) wrote :

GOTO Masanori wrote:

> Yes, I think you're correct. I didn't deny your opinion. So I tagged
> it as wishlist for working future glibc package after sarge.

Whishlist for me means : not a bug. I think if/whenever a NPTL
implementation has a pthread related structure size differerent than a
linuxthread structure size (or define or enum ), you will have a big
problem. Did you even check if it is not already the case NOW?

I will check if I find a posix thread testing suite as anyway I need to
run it to insure the currents status is not indeed already broken + I
need to test my own generated nptl-static-enabled-cvs-libc.

 > Note that I'm feel so not pleasure,
> because we're _not_ your subcontractor for your job.

I've learned for long (8 years running debian and having installed it on
hundreds machines including MP servers, laptop, ...) to _never_ wait
debian for anything. I've been waiting 14 months to have my PPPOA
submitted patche integrated into debian PPP to enable debian users to
use their ADSL modem for example.

Concerning you working as a subcontractor, see :

<http://sources.redhat.com/bugzilla/show_bug.cgi?id=519>

I have averything working but will certainly not try to debug the way
debian choose to generate its libc-dev especially when I see the gentoo
ebuild. I have already a working patched debian/sysdeps/i386.mk to make
it generate a nptl-enabled static libc but the resulting nptl library
set (crt*.o, *.a) does not work and crash at init somewhere during TLS
initialization.

As using the same options on glibc-cvs works, I prefer to go forward as
static linking will probably not interfere much with the rest of debian
generated applications.

--eric

Revision history for this message
In , Daniel Jacobowitz (dan) wrote :

On Sat, Nov 06, 2004 at 03:53:31PM +0100, Eric Valette wrote:
> GOTO Masanori wrote:
>
> >Yes, I think you're correct. I didn't deny your opinion. So I tagged
> >it as wishlist for working future glibc package after sarge.
>
> Whishlist for me means : not a bug. I think if/whenever a NPTL
> implementation has a pthread related structure size differerent than a
> linuxthread structure size (or define or enum ), you will have a big
> problem. Did you even check if it is not already the case NOW?

They are binary compatible, in the set of things exported by both, if
that's what you're asking. Otherwise providing both at runtime would
not work.

> I will check if I find a posix thread testing suite as anyway I need to
> run it to insure the currents status is not indeed already broken + I
> need to test my own generated nptl-static-enabled-cvs-libc.

I recommend the Open POSIX testsuite.

--
Daniel Jacobowitz

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 23:20:42 +0900
From: GOTO Masanori <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: GOTO Masanori <email address hidden>,
 Daniel Jacobowitz <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic
 linking

At Sat, 06 Nov 2004 13:34:27 +0100,
Eric Valette wrote:
> > OK, we will ship /usr/include/nptl in future, like
> > /usr/lib/libpthread.a issue (#276062). I tagged this bug as wishlist,
> > and changed title, and merged with #276062. If you have another
> > comments, please let us know.
> >
> > Regards,
> > -- gotom
>
> I beg to disagree : it is a clear bug to compile with linuxthread
> includes when running NPTL threads. Not a whislist.
>
> Doing this you are behaving like a child saying everything I do is
> perfect. Come on, grow up... And by the way, the debian patched glibc
> does not seem to work with ntpl static...

Yes, I think you're correct. I didn't deny your opinion. So I tagged
it as wishlist for working future glibc package after sarge. It's not
"closing bug". I have tagged for glibc packages as long as I can,
because we have over 400 bugs - it's important to classify which bugs
are user-requested matter, and which bugs are actual glibc code fault.
We're effort to fix bugs (I closed over dozens of bugs in this year),
but everyday we're getting another bugs (and half of bugs are not
glibc related).

It's worthwhile including nptl things. If you want to include it,
it's nice to send your patches. Note that I'm feel so not pleasure,
because we're _not_ your subcontractor for your job.

> A whishlist would be please upgrade to glibc 2.3.3 because your libc is
> so old...

Eric, please calm down.

You need to educate the current status of glibc package. The current
status is "base-freeze". Even if we update it, release managers
decide to drop that package from sarge (and that decision is quite
correct). If you don't read debian-glibc lists, read and search my
opinion. I have been waiting to update glibc over _one year_. I'm
preparing glibc-snapshot package in experimental, so once it's
included in experimental, you can put your patch easily.

Regards,
-- gotom

Revision history for this message
In , EricV (eric-valette) wrote :

Daniel Jacobowitz wrote:

> They are binary compatible, in the set of things exported by both, if
> that's what you're asking. Otherwise providing both at runtime would
> not work.

Thanks for responding and clarifying this. So the remainding problems
are only :
 - Performance,
 - Posix compliance/ different signal behavior,
 - hability to choose between implementation by knwoledgeable users,

>>I will check if I find a posix thread testing suite as anyway I need to
>>run it to insure the currents status is not indeed already broken + I
>>need to test my own generated nptl-static-enabled-cvs-libc.
>
>
> I recommend the Open POSIX testsuite.

Thanks.

-- eric

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 15:53:31 +0100
From: Eric Valette <email address hidden>
To: GOTO Masanori <email address hidden>
Cc: <email address hidden>, Daniel Jacobowitz <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

GOTO Masanori wrote:

> Yes, I think you're correct. I didn't deny your opinion. So I tagged
> it as wishlist for working future glibc package after sarge.

Whishlist for me means : not a bug. I think if/whenever a NPTL
implementation has a pthread related structure size differerent than a
linuxthread structure size (or define or enum ), you will have a big
problem. Did you even check if it is not already the case NOW?

I will check if I find a posix thread testing suite as anyway I need to
run it to insure the currents status is not indeed already broken + I
need to test my own generated nptl-static-enabled-cvs-libc.

 > Note that I'm feel so not pleasure,
> because we're _not_ your subcontractor for your job.

I've learned for long (8 years running debian and having installed it on
hundreds machines including MP servers, laptop, ...) to _never_ wait
debian for anything. I've been waiting 14 months to have my PPPOA
submitted patche integrated into debian PPP to enable debian users to
use their ADSL modem for example.

Concerning you working as a subcontractor, see :

<http://sources.redhat.com/bugzilla/show_bug.cgi?id=519>

I have averything working but will certainly not try to debug the way
debian choose to generate its libc-dev especially when I see the gentoo
ebuild. I have already a working patched debian/sysdeps/i386.mk to make
it generate a nptl-enabled static libc but the resulting nptl library
set (crt*.o, *.a) does not work and crash at init somewhere during TLS
initialization.

As using the same options on glibc-cvs works, I prefer to go forward as
static linking will probably not interfere much with the rest of debian
generated applications.

--eric

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 6 Nov 2004 09:55:53 -0500
From: Daniel Jacobowitz <email address hidden>
To: Eric Valette <email address hidden>
Cc: GOTO Masanori <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic
 linking

On Sat, Nov 06, 2004 at 03:53:31PM +0100, Eric Valette wrote:
> GOTO Masanori wrote:
>
> >Yes, I think you're correct. I didn't deny your opinion. So I tagged
> >it as wishlist for working future glibc package after sarge.
>
> Whishlist for me means : not a bug. I think if/whenever a NPTL
> implementation has a pthread related structure size differerent than a
> linuxthread structure size (or define or enum ), you will have a big
> problem. Did you even check if it is not already the case NOW?

They are binary compatible, in the set of things exported by both, if
that's what you're asking. Otherwise providing both at runtime would
not work.

> I will check if I find a posix thread testing suite as anyway I need to
> run it to insure the currents status is not indeed already broken + I
> need to test my own generated nptl-static-enabled-cvs-libc.

I recommend the Open POSIX testsuite.

--
Daniel Jacobowitz

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 16:00:51 +0100
From: Eric Valette <email address hidden>
To: Daniel Jacobowitz <email address hidden>
Cc: GOTO Masanori <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

Daniel Jacobowitz wrote:

> They are binary compatible, in the set of things exported by both, if
> that's what you're asking. Otherwise providing both at runtime would
> not work.

Thanks for responding and clarifying this. So the remainding problems
are only :
 - Performance,
 - Posix compliance/ different signal behavior,
 - hability to choose between implementation by knwoledgeable users,

>>I will check if I find a posix thread testing suite as anyway I need to
>>run it to insure the currents status is not indeed already broken + I
>>need to test my own generated nptl-static-enabled-cvs-libc.
>
>
> I recommend the Open POSIX testsuite.

Thanks.

-- eric

Revision history for this message
In , EricV (eric-valette) wrote :

Eric Valette wrote:

> Thanks for responding and clarifying this. So the remainding problems
> are only :
> - Performance,
> - Posix compliance/ different signal behavior,
> - hability to choose between implementation by knwoledgeable users,

>> I recommend the Open POSIX testsuite.
>

Here is my report on running posixtestsuite-1.4.3 on two different
environments :
 - The original debian libc-dev using dynamic linking mode but the
LinuxThread related include for pthread and rt many to check if the
current status does not lead to too much errors,
 - My own compiled glibc-cvs for using nptl add-on + patches to make it
compile, using static mode,

I should have run the posixtestsuite-1.4.3 using static mode to show if
nptl posix implementation is as I argued really superior but did not
because anyway I will not use it...

Debian libc6-dev glibc 2.3.2:
------------------------------

cd /home/valette/local/local-src/posixtestsuite-1.4.3
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep PASS | wc -l
1239
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep FAILED | wc -l
28
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep UNRESOLVED | wc -l
16
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep UNTESTED | wc -l
46

It should be noticed that the mq_* tests cannot be generated and that
the status of glibc for dynamic linking is generally in a far more
better shape than the static one...

Debian self compiled glibc 2.3.4-cvs:
--------------------------------------
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep PASS
| wc -l
 1308
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
FAILED | wc -l
25
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
UNRESOLVED | wc -l
77
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
UNTESTED | wc -l
57

==> More test do compile and pass the test, less tests fails. The
UNRESOLVED are not always errors as some just need to be run with
several id...

Now to be complete and fair, one should test the orginal libc6-dev in
static linking mode...

If any of you wants the patche to glibc-cvs to make it compile and do
what is exepcted he is welcomed...

-- eric

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 11 Nov 2004 23:14:52 +0100
From: Eric Valette <email address hidden>
To: <email address hidden>
Cc: Daniel Jacobowitz <email address hidden>,
 GOTO Masanori <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

Eric Valette wrote:

> Thanks for responding and clarifying this. So the remainding problems
> are only :
> - Performance,
> - Posix compliance/ different signal behavior,
> - hability to choose between implementation by knwoledgeable users,

>> I recommend the Open POSIX testsuite.
>

Here is my report on running posixtestsuite-1.4.3 on two different
environments :
 - The original debian libc-dev using dynamic linking mode but the
LinuxThread related include for pthread and rt many to check if the
current status does not lead to too much errors,
 - My own compiled glibc-cvs for using nptl add-on + patches to make it
compile, using static mode,

I should have run the posixtestsuite-1.4.3 using static mode to show if
nptl posix implementation is as I argued really superior but did not
because anyway I will not use it...

Debian libc6-dev glibc 2.3.2:
------------------------------

cd /home/valette/local/local-src/posixtestsuite-1.4.3
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep PASS | wc -l
1239
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep FAILED | wc -l
28
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep UNRESOLVED | wc -l
16
tri-yann:/home/valette/local/local-src/posixtestsuite-1.4.3# grep
execution logfile-debian-original | grep UNTESTED | wc -l
46

It should be noticed that the mq_* tests cannot be generated and that
the status of glibc for dynamic linking is generally in a far more
better shape than the static one...

Debian self compiled glibc 2.3.4-cvs:
--------------------------------------
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep PASS
| wc -l
 1308
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
FAILED | wc -l
25
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
UNRESOLVED | wc -l
77
tri-yann:/home/posixtestsuite-1.4.3# grep execution logfile | grep
UNTESTED | wc -l
57

==> More test do compile and pass the test, less tests fails. The
UNRESOLVED are not always errors as some just need to be run with
several id...

Now to be complete and fair, one should test the orginal libc6-dev in
static linking mode...

If any of you wants the patche to glibc-cvs to make it compile and do
what is exepcted he is welcomed...

-- eric

Revision history for this message
In , EricV (eric-valette) wrote :

Eric Valette wrote:

> Here is my report on running posixtestsuite-1.4.3 on two different
> environments :
> - The original debian libc-dev using dynamic linking mode but the
> LinuxThread related include for pthread and rt many to check if the
> current status does not lead to too much errors,
> - My own compiled glibc-cvs for using nptl add-on + patches to make
> it compile, using static mode,
>

As I did a chroot on a debootstraped sid partiton without mounting /proc
and other virtualfs (including /sys and /dev/shm) the result for the
tests where incorrect for my own generated libc. (The results for the
native libc6-dev were of course correct as I run them on my regular
debian system and did execute the /etc/init/* scripts). Here are the
good ones...

So the correct comparsion table is :

 --------------------------------------------------
 | Original Libc6-dev | Up to date cvs (static) |
 --------------------------------------------------
 | PASS : 1239 | PASS : 1384 |
 | FAILED : 28 | FAILED : 18 |
 | UNTESTED : 46 | UNTESTED : 5 |
 | UNRESOLVED : 16 | UNRESOLVED : 9 |
 --------------------------------------------------

My analysis is :
 - More test can be compiled because of using the correct includes
(especially the mq_* test) => more tests run
 - Less failure due to bugfixes integrated in current glibc-cvs

NB : probably the figures using the linuxtread static version would be
even far worse.

--
    __
   / ` Eric Valette
  /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Fri, 12 Nov 2004 11:02:25 +0100
From: Eric Valette <email address hidden>
To: <email address hidden>
Cc: Daniel Jacobowitz <email address hidden>,
 GOTO Masanori <email address hidden>, <email address hidden>
Subject: Re: Bug#279423: libc6-dev: totally incoherent pthread related includes
 files for dynamic linking

Eric Valette wrote:

> Here is my report on running posixtestsuite-1.4.3 on two different
> environments :
> - The original debian libc-dev using dynamic linking mode but the
> LinuxThread related include for pthread and rt many to check if the
> current status does not lead to too much errors,
> - My own compiled glibc-cvs for using nptl add-on + patches to make
> it compile, using static mode,
>

As I did a chroot on a debootstraped sid partiton without mounting /proc
and other virtualfs (including /sys and /dev/shm) the result for the
tests where incorrect for my own generated libc. (The results for the
native libc6-dev were of course correct as I run them on my regular
debian system and did execute the /etc/init/* scripts). Here are the
good ones...

So the correct comparsion table is :

 --------------------------------------------------
 | Original Libc6-dev | Up to date cvs (static) |
 --------------------------------------------------
 | PASS : 1239 | PASS : 1384 |
 | FAILED : 28 | FAILED : 18 |
 | UNTESTED : 46 | UNTESTED : 5 |
 | UNRESOLVED : 16 | UNRESOLVED : 9 |
 --------------------------------------------------

My analysis is :
 - More test can be compiled because of using the correct includes
(especially the mq_* test) => more tests run
 - Less failure due to bugfixes integrated in current glibc-cvs

NB : probably the figures using the linuxtread static version would be
even far worse.

--
    __
   / ` Eric Valette
  /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
In , GOTO Masanori (gotom) wrote : Fixed in upload of glibc 2.3.5-1 to experimental
Download full text (4.8 KiB)

tag 276062 + fixed-in-experimental
tag 279423 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 10 Apr 2005 14:02:19 +0900
Source: glibc
Binary: libc6-i686 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-1
Distribution: experimental
Urgency: low
Maintainer: GOTO Masanori <email address hidden>
Changed-By: GOTO Masanori <email address hidden>
Description:
 glibc-doc - GNU C Library: Documentation
 libc6 - GNU C Library: Shared libraries and Timezone data
 libc6-dbg - GNU C Library: Libraries with debugging symbols
 libc6-dev - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales - GNU C Library: National Language (locale) data [support]
 nscd - GNU C Library: Name Service Cache Daemon
Closes: 276062 279423
Changes:
 glibc (2.3.5-1) experimental; urgency=low
 .
   * GOTO Masanori <email address hidden>
 .
     * New upstream release.
       - debian/shlibver: Bump up to 2.3.5-1.
 .
     * Drop patches:
       - debian/patches/hurd-malloc.dpatch: Removed, it's already applied in
         the upstream source.
 .
     * Merge with 2.3.2.ds1-21, added:
       - debian/patches/linuxthreads-sizefix.dpatch: Added.
       - debian/po/fi.po: Added.
       - debian/patches/glibc23-mips-lazy-eval.dpatch: Added, drop dl-machine.h
         because the recent upstream should not need such change.
       - debian/patches/glibc232-tls-crashfix.dpatch: Added, remove some parts
         that are applied in the recent version.
 .
     * Merge with 2.3.2.ds1-21, changed:
       - debian/debhelper.in/libc.preinst: Fix typo, proofreading.
       - debian/debhelper.in/libc.preinst: Add export LC_ALL=C.
       - debian/patches/00list: Update.
 .
     * Update linuxthreads size fix for not only ia64, but also alpha,
       amd64, i386, powerpc, s390, sh and sparc.
       - debian/patches/linuxthreads-sizefix.dpatch: Update.
 .
     * Fix more libc6 upgrade problem from old <= 2.3.4-1:
       - debian/debhelper.in/libc.postinst: Don't use uname -m, use
         dpkg --print-installation-architecture. Hwcappkgs mechanism does not
         work on (ex:) install architecture: i386, kernel architecture: amd64.
       - debian/debhelper.in/libc.postrm: Likewise.
 .
     * Support libc6-dev NPTL static libraries and headers into
       /u...

Read more...

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote : Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1 in experimental

Eric,

I put /usr/include/nptl headers and /usr/lib/nptl static libraries
into glibc 2.3.5-1 which is available in experimental. If you need it
so much, could you test it?
BTW, I recommend to test glibc 2.3.5-1 in chroot environment - because
it's not existed in unstable.

Regards,
-- gotom

Revision history for this message
In , EricV (eric-valette) wrote :

GOTO Masanori wrote:
> Eric,
>
> I put /usr/include/nptl headers and /usr/lib/nptl static libraries
> into glibc 2.3.5-1 which is available in experimental. If you need it
> so much, could you test it?

Sure allthough the project that needed it badly already use it as I
compiled it for them myself. But thanks for packaging it, I will forward
this to them.

> BTW, I recommend to test glibc 2.3.5-1 in chroot environment - because
> it's not existed in unstable.

cat /etc/debian_version
3.1 ==> sid in fact.
2 valette@tri-yann->dpkg -s libc6
Package: libc6
Status: install ok installed
Priority: required
Section: base
Installed-Size: 15472
Maintainer: GNU Libc Maintainers <email address hidden>
Architecture: i386
Source: glibc
Version: 2.3.4-3 <======= Not far
Replaces: ldso (<= 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, libc6-bin, netkit-rpc, netbase (<< 4.0), libc6-dev (<<
2.3.2.ds1-14)
Provides: glibc-2.3.4-3
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace (<< 4.0-0), libnss-db (<= 2.2-6.1.1), timezone,
timezones, gconv-modules, libtricks, libc6-doc, libc5 (<< 5.4.33-7),
libpthread0 (<< 0.7-10), libc6-bin, libwcsmbs, apt (<< 0.3.0),
libglib1.2 (<< 1.2.1-2), netkit-rpc, wine (<< 0.0.20031118-1),
cyrus-imapd (<< 1.5.19-15)
Description: GNU C Library: Shared libraries and Timezone data
 Contains the standard libraries that are used by nearly all programs on
 the system. This package includes shared versions of the standard C library
 and the standard math library, as well as many others.
 Timezone data is also included.

No chroot. I'm running this for about two weeks on my two personnal
computers and also on my professionnal computer.

Thanks for coming back.

--
   __
  / ` Eric Valette
 /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (5.0 KiB)

Message-Id: <email address hidden>
Date: Mon, 18 Apr 2005 03:47:50 -0400
From: GOTO Masanori <email address hidden>
To: <email address hidden>
Cc: GOTO Masanori <email address hidden>
Subject: Fixed in upload of glibc 2.3.5-1 to experimental

tag 276062 + fixed-in-experimental
tag 279423 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 10 Apr 2005 14:02:19 +0900
Source: glibc
Binary: libc6-i686 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-1
Distribution: experimental
Urgency: low
Maintainer: GOTO Masanori <email address hidden>
Changed-By: GOTO Masanori <email address hidden>
Description:
 glibc-doc - GNU C Library: Documentation
 libc6 - GNU C Library: Shared libraries and Timezone data
 libc6-dbg - GNU C Library: Libraries with debugging symbols
 libc6-dev - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales - GNU C Library: National Language (locale) data [support]
 nscd - GNU C Library: Name Service Cache Daemon
Closes: 276062 279423
Changes:
 glibc (2.3.5-1) experimental; urgency=low
 .
   * GOTO Masanori <email address hidden>
 .
     * New upstream release.
       - debian/shlibver: Bump up to 2.3.5-1.
 .
     * Drop patches:
       - debian/patches/hurd-malloc.dpatch: Removed, it's already applied in
         the upstream source.
 .
     * Merge with 2.3.2.ds1-21, added:
       - debian/patches/linuxthreads-sizefix.dpatch: Added.
       - debian/po/fi.po: Added.
       - debian/patches/glibc23-mips-lazy-eval.dpatch: Added, drop dl-machine.h
         because the recent upstream should not need such change.
       - debian/patches/glibc232-tls-crashfix.dpatch: Added, remove some parts
         that are applied in the recent version.
 .
     * Merge with 2.3.2.ds1-21, changed:
       - debian/debhelper.in/libc.preinst: Fix typo, proofreading.
       - debian/debhelper.in/libc.preinst: Add export LC_ALL=C.
       - debian/patches/00list: Update.
 .
     * Update linuxthreads size fix for not only ia64, but also alpha,
       amd64, i386, powerpc, s390, sh and sparc.
       - debian/patches/linuxthreads-sizefix.dpatch: Update.
 .
     * Fix more libc6 upgrade problem from old <= 2.3.4-1:
       - debian/debhelper.in/libc.postinst: Don't use uname -m, use
         dpkg --print-installation...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 19:16:42 +0900
From: GOTO Masanori <email address hidden>
To: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1 in experimental

Eric,

I put /usr/include/nptl headers and /usr/lib/nptl static libraries
into glibc 2.3.5-1 which is available in experimental. If you need it
so much, could you test it?
BTW, I recommend to test glibc 2.3.5-1 in chroot environment - because
it's not existed in unstable.

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 20:51:49 +0200
From: Eric Valette <email address hidden>
To: GOTO Masanori <email address hidden>
CC: <email address hidden>, <email address hidden>
Subject: Re: Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1
 in experimental

GOTO Masanori wrote:
> Eric,
>
> I put /usr/include/nptl headers and /usr/lib/nptl static libraries
> into glibc 2.3.5-1 which is available in experimental. If you need it
> so much, could you test it?

Sure allthough the project that needed it badly already use it as I
compiled it for them myself. But thanks for packaging it, I will forward
this to them.

> BTW, I recommend to test glibc 2.3.5-1 in chroot environment - because
> it's not existed in unstable.

cat /etc/debian_version
3.1 ==> sid in fact.
2 valette@tri-yann->dpkg -s libc6
Package: libc6
Status: install ok installed
Priority: required
Section: base
Installed-Size: 15472
Maintainer: GNU Libc Maintainers <email address hidden>
Architecture: i386
Source: glibc
Version: 2.3.4-3 <======= Not far
Replaces: ldso (<= 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, libc6-bin, netkit-rpc, netbase (<< 4.0), libc6-dev (<<
2.3.2.ds1-14)
Provides: glibc-2.3.4-3
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace (<< 4.0-0), libnss-db (<= 2.2-6.1.1), timezone,
timezones, gconv-modules, libtricks, libc6-doc, libc5 (<< 5.4.33-7),
libpthread0 (<< 0.7-10), libc6-bin, libwcsmbs, apt (<< 0.3.0),
libglib1.2 (<< 1.2.1-2), netkit-rpc, wine (<< 0.0.20031118-1),
cyrus-imapd (<< 1.5.19-15)
Description: GNU C Library: Shared libraries and Timezone data
 Contains the standard libraries that are used by nearly all programs on
 the system. This package includes shared versions of the standard C library
 and the standard math library, as well as many others.
 Timezone data is also included.

No chroot. I'm running this for about two weeks on my two personnal
computers and also on my professionnal computer.

Thanks for coming back.

--
   __
  / ` Eric Valette
 /-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace

Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: <email address hidden>

Revision history for this message
Jeff Bailey (jbailey) wrote :

Will pull in the /usr/include/nptl bits for i386 after next resync with Debian.

Revision history for this message
In , EricV (eric-valette) wrote :
Download full text (7.0 KiB)

Eric Valette wrote:
> GOTO Masanori wrote:
>
>>Eric,
>>
>>I put /usr/include/nptl headers and /usr/lib/nptl static libraries
>>into glibc 2.3.5-1 which is available in experimental. If you need it
>>so much, could you test it?

OK I did. It work on a basic test at least :

gcc-3.4 -v -static -I/usr/include/nptl -L/usr/lib/nptl t3.c -o t3 -lpthread

---------------------------------------------------------------------------
Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls
--without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
 /usr/lib/gcc/i486-linux/3.4.4/cc1 -quiet -v -I/usr/include/nptl t3.c
-quiet -dumpbase t3.c -mtune=i486 -auxbase t3 -version -o /tmp/ccMmtk1o.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux/3.4.4/../../../../i486-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/nptl
 /usr/lib/gcc/i486-linux/3.4.4/include
 /usr/include
End of search list.
GNU C version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) (i486-linux)
        compiled by GNU C version 3.4.4 20050314 (prerelease) (Debian
3.4.3-12).GGC heuristics: --param ggc-min-expand=64 --param
ggc-min-heapsize=64195
t3.c: In function `main':
t3.c:46: warning: passing arg 3 of `pthread_create' from incompatible
pointer type
 as -V -Qy --32 -o /tmp/ccMptMXU.o /tmp/ccMmtk1o.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 /usr/lib/gcc/i486-linux/3.4.4/collect2 -m elf_i386 -static -o t3
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crti.o
/usr/lib/gcc/i486-linux/3.4.4/crtbeginT.o -L/usr/lib/nptl
-L/usr/lib/gcc/i486-linux/3.4.4 -L/usr/lib/gcc/i486-linux/3.4.4
-L/usr/lib/gcc/i486-linux/3.4.4/../../../../lib
-L/usr/lib/gcc/i486-linux/3.4.4/../../.. -L/lib/../lib -L/usr/lib/../lib
/tmp/ccMptMXU.o -lpthread --start-group -lgcc -lgcc_eh -lc --end-group
/usr/lib/gcc/i486-linux/3.4.4/crtend.o
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crtn.o
...

---------------------------------------------------------------------------------
33 tri-yann:~/tmp->strace -f t3
execve("./t3", ["t3"], [/* 79 vars */]) = 0
uname({sys="Linux", node="tri-yann", ...}) = 0
brk(0) = 0x80be000
brk(0x80bec90) = 0x80bec90
set_thread_area({entry_number:-1 -> 6, base_addr:0x80be830,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
set_tid_address(0x80be878) = 9183
rt_sigaction(SIGRTMIN, {0x804ab30, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x804abb0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_...

Read more...

Revision history for this message
Jeff Bailey (jbailey) wrote :

Should be fixed in glibc-2.3.5-1ubuntu1.

Revision history for this message
In , GOTO Masanori (gotom) wrote : Bug#276062: fixed in glibc 2.3.5-3
Download full text (30.1 KiB)

Source: glibc
Source-Version: 2.3.5-3

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-3_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-3_all.deb
glibc_2.3.5-3.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-3.diff.gz
glibc_2.3.5-3.dsc
  to pool/main/g/glibc/glibc_2.3.5-3.dsc
libc6-dbg_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_arm.deb
libc6-dbg_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_hppa.deb
libc6-dbg_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_i386.deb
libc6-dbg_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mips.deb
libc6-dbg_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mipsel.deb
libc6-dbg_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_powerpc.deb
libc6-dbg_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_s390.deb
libc6-dbg_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_sparc.deb
libc6-dev-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev-ppc64_2.3.5-3_powerpc.deb
libc6-dev-s390x_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev-s390x_2.3.5-3_s390.deb
libc6-dev-sparc64_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev-sparc64_2.3.5-3_sparc.deb
libc6-dev_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_arm.deb
libc6-dev_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_hppa.deb
libc6-dev_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_i386.deb
libc6-dev_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mips.deb
libc6-dev_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mipsel.deb
libc6-dev_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_powerpc.deb
libc6-dev_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_s390.deb
libc6-dev_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_sparc.deb
libc6-i686_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_arm.deb
libc6-pic_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_hppa.deb
libc6-pic_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mips.deb
libc6-pic_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mipsel.deb
libc6-pic_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_powerpc.deb
libc6-pic_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_s390.deb
libc6-pic_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_sparc.deb
libc6-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-ppc64_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_arm.deb
libc6-prof_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_hppa.deb
libc6-prof_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_i386.deb
libc6-prof_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_mips.deb
libc6-prof_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_mipsel.deb
libc6-prof_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_s...

Revision history for this message
In , GOTO Masanori (gotom) wrote : Bug#279423: fixed in glibc 2.3.5-3
Download full text (30.1 KiB)

Source: glibc
Source-Version: 2.3.5-3

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-3_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-3_all.deb
glibc_2.3.5-3.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-3.diff.gz
glibc_2.3.5-3.dsc
  to pool/main/g/glibc/glibc_2.3.5-3.dsc
libc6-dbg_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_arm.deb
libc6-dbg_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_hppa.deb
libc6-dbg_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_i386.deb
libc6-dbg_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mips.deb
libc6-dbg_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mipsel.deb
libc6-dbg_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_powerpc.deb
libc6-dbg_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_s390.deb
libc6-dbg_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_sparc.deb
libc6-dev-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev-ppc64_2.3.5-3_powerpc.deb
libc6-dev-s390x_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev-s390x_2.3.5-3_s390.deb
libc6-dev-sparc64_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev-sparc64_2.3.5-3_sparc.deb
libc6-dev_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_arm.deb
libc6-dev_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_hppa.deb
libc6-dev_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_i386.deb
libc6-dev_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mips.deb
libc6-dev_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mipsel.deb
libc6-dev_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_powerpc.deb
libc6-dev_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_s390.deb
libc6-dev_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_sparc.deb
libc6-i686_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_arm.deb
libc6-pic_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_hppa.deb
libc6-pic_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mips.deb
libc6-pic_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mipsel.deb
libc6-pic_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_powerpc.deb
libc6-pic_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_s390.deb
libc6-pic_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_sparc.deb
libc6-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-ppc64_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_arm.deb
libc6-prof_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_hppa.deb
libc6-prof_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_i386.deb
libc6-prof_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_mips.deb
libc6-prof_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_mipsel.deb
libc6-prof_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_s...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (7.4 KiB)

Message-ID: <email address hidden>
Date: Sat, 23 Apr 2005 15:31:04 +0200
From: Eric Valette <email address hidden>
To: <email address hidden>, GOTO Masanori <email address hidden>
CC: <email address hidden>, <email address hidden>,
 Nicolas Mabire <email address hidden>
Subject: Re: Please test /usr/include/nptl and /usr/lib/nptl with glibc 2.3.5-1
 in experimental

Eric Valette wrote:
> GOTO Masanori wrote:
>
>>Eric,
>>
>>I put /usr/include/nptl headers and /usr/lib/nptl static libraries
>>into glibc 2.3.5-1 which is available in experimental. If you need it
>>so much, could you test it?

OK I did. It work on a basic test at least :

gcc-3.4 -v -static -I/usr/include/nptl -L/usr/lib/nptl t3.c -o t3 -lpthread

---------------------------------------------------------------------------
Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls
--without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
 /usr/lib/gcc/i486-linux/3.4.4/cc1 -quiet -v -I/usr/include/nptl t3.c
-quiet -dumpbase t3.c -mtune=i486 -auxbase t3 -version -o /tmp/ccMmtk1o.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux/3.4.4/../../../../i486-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/nptl
 /usr/lib/gcc/i486-linux/3.4.4/include
 /usr/include
End of search list.
GNU C version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) (i486-linux)
        compiled by GNU C version 3.4.4 20050314 (prerelease) (Debian
3.4.3-12).GGC heuristics: --param ggc-min-expand=64 --param
ggc-min-heapsize=64195
t3.c: In function `main':
t3.c:46: warning: passing arg 3 of `pthread_create' from incompatible
pointer type
 as -V -Qy --32 -o /tmp/ccMptMXU.o /tmp/ccMmtk1o.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 /usr/lib/gcc/i486-linux/3.4.4/collect2 -m elf_i386 -static -o t3
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crti.o
/usr/lib/gcc/i486-linux/3.4.4/crtbeginT.o -L/usr/lib/nptl
-L/usr/lib/gcc/i486-linux/3.4.4 -L/usr/lib/gcc/i486-linux/3.4.4
-L/usr/lib/gcc/i486-linux/3.4.4/../../../../lib
-L/usr/lib/gcc/i486-linux/3.4.4/../../.. -L/lib/../lib -L/usr/lib/../lib
/tmp/ccMptMXU.o -lpthread --start-group -lgcc -lgcc_eh -lc --end-group
/usr/lib/gcc/i486-linux/3.4.4/crtend.o
/usr/lib/gcc/i486-linux/3.4.4/../../../../lib/crtn.o
...

---------------------------------------------------------------------------------
33 tri-yann:~/tmp->strace -f t3
execve("./t3", ["t3"], [/* 79 vars */]) = 0
uname({sys="Linux", node="tri-yann", ...}) = 0
brk(0) = 0x80be000
brk(0x80bec90) = 0x80bec90
set_thread_area({entry_num...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (30.3 KiB)

Message-Id: <email address hidden>
Date: Fri, 05 Aug 2005 03:29:24 -0700
From: GOTO Masanori <email address hidden>
To: <email address hidden>
Subject: Bug#276062: fixed in glibc 2.3.5-3

Source: glibc
Source-Version: 2.3.5-3

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-3_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-3_all.deb
glibc_2.3.5-3.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-3.diff.gz
glibc_2.3.5-3.dsc
  to pool/main/g/glibc/glibc_2.3.5-3.dsc
libc6-dbg_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_arm.deb
libc6-dbg_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_hppa.deb
libc6-dbg_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_i386.deb
libc6-dbg_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mips.deb
libc6-dbg_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mipsel.deb
libc6-dbg_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_powerpc.deb
libc6-dbg_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_s390.deb
libc6-dbg_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_sparc.deb
libc6-dev-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev-ppc64_2.3.5-3_powerpc.deb
libc6-dev-s390x_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev-s390x_2.3.5-3_s390.deb
libc6-dev-sparc64_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev-sparc64_2.3.5-3_sparc.deb
libc6-dev_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_arm.deb
libc6-dev_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_hppa.deb
libc6-dev_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_i386.deb
libc6-dev_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mips.deb
libc6-dev_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mipsel.deb
libc6-dev_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_powerpc.deb
libc6-dev_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_s390.deb
libc6-dev_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_sparc.deb
libc6-i686_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_arm.deb
libc6-pic_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_hppa.deb
libc6-pic_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mips.deb
libc6-pic_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mipsel.deb
libc6-pic_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_powerpc.deb
libc6-pic_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_s390.deb
libc6-pic_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_sparc.deb
libc6-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-ppc64_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_arm.deb
libc6-prof_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_hppa.deb
libc6-prof_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_i386.deb
libc6-prof_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-prof_2...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (30.3 KiB)

Message-Id: <email address hidden>
Date: Fri, 05 Aug 2005 03:29:24 -0700
From: GOTO Masanori <email address hidden>
To: <email address hidden>
Subject: Bug#279423: fixed in glibc 2.3.5-3

Source: glibc
Source-Version: 2.3.5-3

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-3_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-3_all.deb
glibc_2.3.5-3.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-3.diff.gz
glibc_2.3.5-3.dsc
  to pool/main/g/glibc/glibc_2.3.5-3.dsc
libc6-dbg_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_arm.deb
libc6-dbg_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_hppa.deb
libc6-dbg_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_i386.deb
libc6-dbg_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mips.deb
libc6-dbg_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_mipsel.deb
libc6-dbg_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_powerpc.deb
libc6-dbg_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_s390.deb
libc6-dbg_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-3_sparc.deb
libc6-dev-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev-ppc64_2.3.5-3_powerpc.deb
libc6-dev-s390x_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev-s390x_2.3.5-3_s390.deb
libc6-dev-sparc64_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev-sparc64_2.3.5-3_sparc.deb
libc6-dev_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_arm.deb
libc6-dev_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_hppa.deb
libc6-dev_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_i386.deb
libc6-dev_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mips.deb
libc6-dev_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_mipsel.deb
libc6-dev_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_powerpc.deb
libc6-dev_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_s390.deb
libc6-dev_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-3_sparc.deb
libc6-i686_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_arm.deb
libc6-pic_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_hppa.deb
libc6-pic_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_i386.deb
libc6-pic_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mips.deb
libc6-pic_2.3.5-3_mipsel.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_mipsel.deb
libc6-pic_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_powerpc.deb
libc6-pic_2.3.5-3_s390.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_s390.deb
libc6-pic_2.3.5-3_sparc.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-3_sparc.deb
libc6-ppc64_2.3.5-3_powerpc.deb
  to pool/main/g/glibc/libc6-ppc64_2.3.5-3_powerpc.deb
libc6-prof_2.3.5-3_arm.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_arm.deb
libc6-prof_2.3.5-3_hppa.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_hppa.deb
libc6-prof_2.3.5-3_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-3_i386.deb
libc6-prof_2.3.5-3_mips.deb
  to pool/main/g/glibc/libc6-prof_2...

Revision history for this message
In , Dano Callen (danocallen) wrote : string Karzai thanks

Rain in torrents fought the fires below.

AN ALLE FINANZINVESTOREN!
DIESE AKTIE WIRD DURCHSTARTEN!
FREITAG 20. APRIL STARTET DIE HAUSSE!
REALISIERTER KURSGEWINN VON 400%+ IN 5 TAGEN!

Symbol: G7Q.F
Company: COUNTY LINE ENERGY
5 Tages Kursziel: 0.95
Schlusskurs: 0.21
WKN: A0J3B0
ISIN: US2224791077
Markt: Frankfurt

LASSEN SIE SICH DIESE CHANCE NICHT ENTGEHEN!
G7Q WIRD WIE EINE RAKETE DURCHSTARTEN!
UNSERE ERWARTUNGEN WIRD G7Q.F UBERTREFFEN!

Jen vi --- ordinara.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.