v2: The GNU C Library 2.16 release plan

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

v2: The GNU C Library 2.16 release plan

Carlos O'Donell-4
Community,

I would like to freeze trunk for a 2.16 release starting June 4th.

There are 3 more weeks of active development left.

The freeze has been pushed back 3 weeks:
~~~
* We want to allow for x32 to be included in the release. Please help review x32 patches!

* Andreas Jaegar has a suggested these bugs:

  Blockers:
  http://sourceware.org/bugzilla/show_bug.cgi?id=13579
  http://sourceware.org/bugzilla/show_bug.cgi?id=13594

  Needs review:
  http://sourceware.org/bugzilla/show_bug.cgi?id=13939
  http://sourceware.org/bugzilla/show_bug.cgi?id=13882

  Please help!

* Joseph Myers would like to see Paul Eggert's approved patches checked in.

* Ryan Arnold has outstanding PowerPC math library fixes to verify and checkin.
~~~

The timeline looks like this:

* Development freeze of trunk on Monday June 4th.

  * Last day of active development is Sunday June 3rd.

* [3 weeks] Ask all machine maintainers to test and report back the status of their machines.

  * Updating ABI files so ABI check passes.

  * Updating ULPs for the release.

  * Regenerating any machine files that are out of date.

  If I hear back from the machine maintainers quickly then this might be as short as 1-2 days and we release early.

* [1 week] Between June 25th-29th I will branch master to the 2.16 branch and, after any last minute tweaks, tag it for a final release.

* The release will be made on the first week of July.

http://sourceware.org/glibc/wiki/Glibc%20Timeline

http://sourceware.org/glibc/wiki/Release

Comments?

Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
[hidden email]
[hidden email]
+1 (613) 963 1026
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Jeff Law
On 05/10/2012 04:23 PM, Carlos O'Donell wrote:

>
> The timeline looks like this:
>
> * Development freeze of trunk on Monday June 4th.
>
>    * Last day of active development is Sunday June 3rd.
>
> * [3 weeks] Ask all machine maintainers to test and report back the status of their machines.
>
>    * Updating ABI files so ABI check passes.
>
>    * Updating ULPs for the release.
>
>    * Regenerating any machine files that are out of date.
>
>    If I hear back from the machine maintainers quickly then this might be as short as 1-2 days and we release early.
>
> * [1 week] Between June 25th-29th I will branch master to the 2.16 branch and, after any last minute tweaks, tag it for a final release.
>
> * The release will be made on the first week of July.
>
> http://sourceware.org/glibc/wiki/Glibc%20Timeline
>
> http://sourceware.org/glibc/wiki/Release
Seems pretty reasonable.  I don't see that there'll be time to dive into
the ongoing problems with pthread_cond_wait on x86/x86_64, so the
distros will likely continue to hack that up.

Time scale looks good for Fedora; I'd probably look to update fedora
rawhide in the next week or so to track the 2.16 bits.

Jeff
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Allan McRae-3
On 11/05/12 13:26, Jeff Law wrote:

> On 05/10/2012 04:23 PM, Carlos O'Donell wrote:
>
>>
>> The timeline looks like this:
>>
>> * Development freeze of trunk on Monday June 4th.
>>
>>    * Last day of active development is Sunday June 3rd.
>>
>> * [3 weeks] Ask all machine maintainers to test and report back the
>> status of their machines.
>>
>>    * Updating ABI files so ABI check passes.
>>
>>    * Updating ULPs for the release.
>>
>>    * Regenerating any machine files that are out of date.
>>
>>    If I hear back from the machine maintainers quickly then this might
>> be as short as 1-2 days and we release early.
>>
>> * [1 week] Between June 25th-29th I will branch master to the 2.16
>> branch and, after any last minute tweaks, tag it for a final release.
>>
>> * The release will be made on the first week of July.
>>
>> http://sourceware.org/glibc/wiki/Glibc%20Timeline
>>
>> http://sourceware.org/glibc/wiki/Release
> Seems pretty reasonable.  I don't see that there'll be time to dive into
> the ongoing problems with pthread_cond_wait on x86/x86_64, so the
> distros will likely continue to hack that up.
>

Is there a bug report open for that issue?  I found various distribution
ones, but non in the glibc tracker.


Apart from that issue, the only patch in the Arch Linux package that is
not flagged for glibc-2.16 is for the assertion error in res_query.c
[1]. This has been around since glibc-2.14 and from memory the patch in
that report is widely used.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=13013

Allan
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Carlos O'Donell-4
In reply to this post by Jeff Law
On 5/10/2012 11:26 PM, Jeff Law wrote:
> On 05/10/2012 04:23 PM, Carlos O'Donell wrote:
>> * The release will be made on the first week of July.
>>
>> http://sourceware.org/glibc/wiki/Glibc%20Timeline
>>
>> http://sourceware.org/glibc/wiki/Release
> Seems pretty reasonable.  I don't see that there'll be time to dive into the ongoing problems with pthread_cond_wait on x86/x86_64, so the distros will likely continue to hack that up.
>
> Time scale looks good for Fedora; I'd probably look to update fedora rawhide in the next week or so to track the 2.16 bits.

Thanks for the feedback Jeff.

Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
[hidden email]
[hidden email]
+1 (613) 963 1026
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

H.J. Lu-30
In reply to this post by Carlos O'Donell-4
On Thu, May 10, 2012 at 3:23 PM, Carlos O'Donell
<[hidden email]> wrote:

> Community,
>
> I would like to freeze trunk for a 2.16 release starting June 4th.
>
> There are 3 more weeks of active development left.
>
> The freeze has been pushed back 3 weeks:
> ~~~
> * We want to allow for x32 to be included in the release. Please help review x32 patches!
>

I would really appreciate feedbacks on my x32 patches.

Thanks.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Roland McGrath-4
> I would really appreciate feedbacks on my x32 patches.

I thoroughly intend to put most of my time in the next few days
(excluding the weekend) into that.
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Jeff Law
In reply to this post by Allan McRae-3
On 05/10/2012 11:47 PM, Allan McRae wrote:

> Is there a bug report open for that issue?  I found various distribution
> ones, but non in the glibc tracker.
I don't think so.  I think Red Hat's 552960 has the most amount of
relevant information, including instructions to hang a system that is
using the pthread_cond_* bits currently on the trunk.


>
> Apart from that issue, the only patch in the Arch Linux package that is
> not flagged for glibc-2.16 is for the assertion error in res_query.c
> [1]. This has been around since glibc-2.14 and from memory the patch in
> that report is widely used.
>
> [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13013
Yup.  Well known problem.  Unfortunately triggering the problem requires
access to poorly acting DNS servers, which is why Uli was never able to
trigger the problem.  Fedora is currently using Aurelien's patch.

We've got a mess of locale fixes and a few other randoms in Fedora that
need to be submitted or resolved upstream.  I'm hoping to get that
process rolling soon.  Nothing I'd consider terribly critical for 2.16.


jeff
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Joseph Myers
In reply to this post by Carlos O'Donell-4
On Thu, 10 May 2012, Carlos O'Donell wrote:

> * Development freeze of trunk on Monday June 4th.
>
>   * Last day of active development is Sunday June 3rd.
>
> * [3 weeks] Ask all machine maintainers to test and report back the
> status of their machines.
>
>   * Updating ABI files so ABI check passes.
>
>   * Updating ULPs for the release.
>
>   * Regenerating any machine files that are out of date.
>
>   If I hear back from the machine maintainers quickly then this might be
> as short as 1-2 days and we release early.

I don't think 1-2 days is sensibly practical here.

- The freeze is meant to allow time for ports maintainers to bring sysdeps
files up to date with libc changes.  There have been a lot of libc changes
lately requiring corresponding ports changes, many of which (e.g. some
INTDEF/INTUSE changes) have not been called out by their submitters has
involving such port changes.  I've been spending most of today simply
keeping ARM, MIPS and powerpc-nofpu up to date with the changes as they go
into libc today.  I'm sure you have a rather bigger accumulation of hppa
changes to make....

- It's quite likely testing shows up problems that need investigation and
fixing rather than everything being as clean as one might hope.  My
initial attempt at updating MIPS ULPs ran into what looks like a
miscompilation of ilogbl with current trunk GCC, I'm now retrying with GCC
4.7 branch.

- Some people have multiple ports or port variants to test and resolve
problems with.  I have four ARM ABIs (big and little endian, hard and soft
float ABIs - though I'm not sure about finding any suitable physical or
virtual system for testing the hard-float ABI, big-endian combination, so
that may just be limited QEMU userspace emulation testing), twelve MIPS
ABIs (big and little endian, hard and soft float, o32, n32 and n64) and
powerpc-nofpu to validate.

Three weeks seems a more practical time for architecture maintainers in
libc and ports to ensure their architectures are up to date and have good
test results not indicating architecture-specific problems.  Here freeze
needs to be understood in terms of avoiding any patches likely to need
per-architecture updates (even if those updates are mechanical) or
involving risk of per-architecture breakage more than avoiding changes in
other areas of glibc.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

David Miller-13
From: "Joseph S. Myers" <[hidden email]>
Date: Thu, 31 May 2012 00:13:31 +0000 (UTC)

> Three weeks seems a more practical time for architecture maintainers in
> libc and ports to ensure their architectures are up to date and have good
> test results not indicating architecture-specific problems.  Here freeze
> needs to be understood in terms of avoiding any patches likely to need
> per-architecture updates (even if those updates are mechanical) or
> involving risk of per-architecture breakage more than avoiding changes in
> other areas of glibc.

I agree with Joseph, especially given the fact that we have people
who have to check multiple targets.
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Carlos O'Donell-4
On 5/31/2012 1:35 AM, David Miller wrote:

> From: "Joseph S. Myers" <[hidden email]>
> Date: Thu, 31 May 2012 00:13:31 +0000 (UTC)
>
>> Three weeks seems a more practical time for architecture maintainers in
>> libc and ports to ensure their architectures are up to date and have good
>> test results not indicating architecture-specific problems.  Here freeze
>> needs to be understood in terms of avoiding any patches likely to need
>> per-architecture updates (even if those updates are mechanical) or
>> involving risk of per-architecture breakage more than avoiding changes in
>> other areas of glibc.
>
> I agree with Joseph, especially given the fact that we have people
> who have to check multiple targets.

I agree too!

I'll be posting an update for 2.15.1 and 2.16 shortly.

Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
[hidden email]
[hidden email]
+1 (613) 963 1026
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Joseph Myers
In reply to this post by Joseph Myers
Oh, and one other point about release testing:

GCC routinely gets tested before release by full GNU/Linux distribution
rebuilds - is anyone able to test distribution rebuilds with new glibc
after we freeze for 4.6?  This may be less likely to show up problems than
rebuilds with new GCC are, but it could still be useful.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Jeff Law
On 05/31/2012 12:48 PM, Joseph S. Myers wrote:
> Oh, and one other point about release testing:
>
> GCC routinely gets tested before release by full GNU/Linux distribution
> rebuilds - is anyone able to test distribution rebuilds with new glibc
> after we freeze for 4.6?  This may be less likely to show up problems than
> rebuilds with new GCC are, but it could still be useful.
Dunno if I have any good way to do a full distro rebuild right now,
well, at least not without incurring the wrath of the entire Fedora
development community :-)

We are tracking the trunk (currently at 4d17e683) in Fedora Rawhide.
Issues so far have been entirely Fedora specific.


Jeff
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Josh Boyer-3
On Thu, May 31, 2012 at 2:53 PM, Jeff Law <[hidden email]> wrote:

> On 05/31/2012 12:48 PM, Joseph S. Myers wrote:
>>
>> Oh, and one other point about release testing:
>>
>> GCC routinely gets tested before release by full GNU/Linux distribution
>> rebuilds - is anyone able to test distribution rebuilds with new glibc
>> after we freeze for 4.6?  This may be less likely to show up problems than
>> rebuilds with new GCC are, but it could still be useful.
>
> Dunno if I have any good way to do a full distro rebuild right now, well, at
> least not without incurring the wrath of the entire Fedora development
> community :-)
>

You can actually do this in a side koji tag or on a Fedora
infrastructure build box somewhere.  It might be doable, just need to
talk to the right people.

Fedora rebuilds whenever a new GCC necessitates it, but that likely
isn't going to coincide with glibc releases, somewhat unfortuantely.

> We are tracking the trunk (currently at 4d17e683) in Fedora Rawhide. Issues
> so far have been entirely Fedora specific.

Except for the bits/sysctl.h issue, which a patch has been posted for.

josh
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Jeff Law
On 05/31/2012 01:14 PM, Josh Boyer wrote:
>>
>
> You can actually do this in a side koji tag or on a Fedora
> infrastructure build box somewhere.  It might be doable, just need to
> talk to the right people.
>
> Fedora rebuilds whenever a new GCC necessitates it, but that likely
> isn't going to coincide with glibc releases, somewhat unfortuantely.
Yes, but the mass rebuilds are fairly disruptive.


>
>> We are tracking the trunk (currently at 4d17e683) in Fedora Rawhide. Issues
>> so far have been entirely Fedora specific.
>
> Except for the bits/sysctl.h issue, which a patch has been posted for.
Haven't gotten to that yet, but it's in my queue.

jeff
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Josh Boyer-3
On Thu, May 31, 2012 at 3:20 PM, Jeff Law <[hidden email]> wrote:

> On 05/31/2012 01:14 PM, Josh Boyer wrote:
>>>
>>>
>>
>> You can actually do this in a side koji tag or on a Fedora
>> infrastructure build box somewhere.  It might be doable, just need to
>> talk to the right people.
>>
>> Fedora rebuilds whenever a new GCC necessitates it, but that likely
>> isn't going to coincide with glibc releases, somewhat unfortuantely.
>
> Yes, but the mass rebuilds are fairly disruptive.

Right!  Which is why I said it could be done with side koji tag or on
a standalone box.  It's a mass rebuild without really doing a mass
rebuild that impacts the Fedora project.  Throw-away builds of a sort.

Jakub has done side koji tags in the past for new gcc releases before
dropping them into rawhide.  It can be done if someone wants spend the
time.

josh
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Mike Frysinger
In reply to this post by Joseph Myers
On Thursday 31 May 2012 14:48:52 Joseph S. Myers wrote:
> Oh, and one other point about release testing:
>
> GCC routinely gets tested before release by full GNU/Linux distribution
> rebuilds - is anyone able to test distribution rebuilds with new glibc
> after we freeze for 4.6?  This may be less likely to show up problems than
> rebuilds with new GCC are, but it could still be useful.

in testing glibc-2.16 and building up a new chroot, i've noticed two issues:

 - a lot of gnulib packages fail with gets() errors ... the gnulib project has
fixed this, but it'll take a while for that to trickle down into all the
respective projects.  i've just added patches like this to fix it:
http://sources.gentoo.org/app-arch/gzip/files/gzip-1.4-no-gets.patch

 - the fortify warning change wrt optimization is too noisy.  i glanced
through gcc to see if the fortify-by-default could be made to work in a
different way, but couldn't see a clean way of doing it.  instead, i'll just
carry this in Gentoo:

--- a/include/features.h
+++ b/include/features.h
@@ -325,10 +325,11 @@
 # define __USE_REENTRANT 1
 #endif
 
+#if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
+# undef _FORTIFY_SOURCE
+#endif
 #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
-# if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
-#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
-# elif !__GNUC_PREREQ (4, 1)
+# if !__GNUC_PREREQ (4, 1)
 #  warning _FORTIFY_SOURCE requires GCC 4.1 or later
 # elif _FORTIFY_SOURCE > 1
 #  define __USE_FORTIFY_LEVEL 2
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Roland McGrath-4
In reply to this post by Josh Boyer-3
> Jakub has done side koji tags in the past for new gcc releases before
> dropping them into rawhide.  It can be done if someone wants spend the
> time.

Indeed.  In the past, there was an outside Fedora volunteer who also did
periodic mass rebuild tests in a similar fashion (not using Koji, I don't
think).  I think it was Matt Domsch.  So it's worth asking him and/or
asking <[hidden email]> for someone willing to do this once
a release-candidate glibc is in Fedora.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Allan McRae-3
In reply to this post by Mike Frysinger
On 01/06/12 05:51, Mike Frysinger wrote:

> On Thursday 31 May 2012 14:48:52 Joseph S. Myers wrote:
>> Oh, and one other point about release testing:
>>
>> GCC routinely gets tested before release by full GNU/Linux distribution
>> rebuilds - is anyone able to test distribution rebuilds with new glibc
>> after we freeze for 4.6?  This may be less likely to show up problems than
>> rebuilds with new GCC are, but it could still be useful.
>
> in testing glibc-2.16 and building up a new chroot, i've noticed two issues:
>
>  - a lot of gnulib packages fail with gets() errors ... the gnulib project has
> fixed this, but it'll take a while for that to trickle down into all the
> respective projects.  i've just added patches like this to fix it:
> http://sources.gentoo.org/app-arch/gzip/files/gzip-1.4-no-gets.patch
>
>  - the fortify warning change wrt optimization is too noisy.  i glanced
> through gcc to see if the fortify-by-default could be made to work in a
> different way, but couldn't see a clean way of doing it.  instead, i'll just
> carry this in Gentoo:
>
> --- a/include/features.h
> +++ b/include/features.h
> @@ -325,10 +325,11 @@
>  # define __USE_REENTRANT 1
>  #endif
>  
> +#if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
> +# undef _FORTIFY_SOURCE
> +#endif
>  #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
> -# if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
> -#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> -# elif !__GNUC_PREREQ (4, 1)
> +# if !__GNUC_PREREQ (4, 1)
>  #  warning _FORTIFY_SOURCE requires GCC 4.1 or later
>  # elif _FORTIFY_SOURCE > 1
>  #  define __USE_FORTIFY_LEVEL 2
> -mike



I have rebuilt the Arch Linux [core] repo (basically software needed for
boot-up and building more software...) with glibc-2.15-1124-gebc64a1 for
x86_64.  I get the following issues:


A bunch of the afore mentioned gnulib/gets issues (bison, diffutils,
gettext, gzip, inetutils, libpipeline, m4, man-db, tar, wget)


This is a genuine bug in glibc:
pciutils-3.1.9:
/usr/include/sys/io.h: In function 'outsw':
/usr/include/sys/io.h:168:51: error: '____addr' undeclared (first use in
this function)
Patch on the way...


I assume these two are missing header issues but have not investigated yet:

busybox-1.19.4:
shell/shell_common.c: In function 'printlim':
shell/shell_common.c:369:2: error: unknown type name 'rlim_t'
shell/shell_common.c:371:13: error: dereferencing pointer to incomplete type
shell/shell_common.c:373:14: error: dereferencing pointer to incomplete type
shell/shell_common.c:375:13: error: 'RLIM_INFINITY' undeclared (first
use in this function)

pam-1.1.5:
pam_unix_acct.c: In function '_unix_run_verify_binary':
pam_unix_acct.c:97:19: error: storage size of 'rlim' isn't known
pam_unix_acct.c:106:19: error: 'RLIMIT_NOFILE' undeclared (first use in
this function)


I saw a couple of other build failures, but I am not sure they are
related at the moment.

Allan
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

H.J. Lu-30
On Fri, Jun 1, 2012 at 5:36 PM, Allan McRae <[hidden email]> wrote:

> On 01/06/12 05:51, Mike Frysinger wrote:
>> On Thursday 31 May 2012 14:48:52 Joseph S. Myers wrote:
>>> Oh, and one other point about release testing:
>>>
>>> GCC routinely gets tested before release by full GNU/Linux distribution
>>> rebuilds - is anyone able to test distribution rebuilds with new glibc
>>> after we freeze for 4.6?  This may be less likely to show up problems than
>>> rebuilds with new GCC are, but it could still be useful.
>>
>> in testing glibc-2.16 and building up a new chroot, i've noticed two issues:
>>
>>  - a lot of gnulib packages fail with gets() errors ... the gnulib project has
>> fixed this, but it'll take a while for that to trickle down into all the
>> respective projects.  i've just added patches like this to fix it:
>> http://sources.gentoo.org/app-arch/gzip/files/gzip-1.4-no-gets.patch
>>
>>  - the fortify warning change wrt optimization is too noisy.  i glanced
>> through gcc to see if the fortify-by-default could be made to work in a
>> different way, but couldn't see a clean way of doing it.  instead, i'll just
>> carry this in Gentoo:
>>
>> --- a/include/features.h
>> +++ b/include/features.h
>> @@ -325,10 +325,11 @@
>>  # define __USE_REENTRANT     1
>>  #endif
>>
>> +#if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
>> +# undef _FORTIFY_SOURCE
>> +#endif
>>  #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
>> -# if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
>> -#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
>> -# elif !__GNUC_PREREQ (4, 1)
>> +# if !__GNUC_PREREQ (4, 1)
>>  #  warning _FORTIFY_SOURCE requires GCC 4.1 or later
>>  # elif _FORTIFY_SOURCE > 1
>>  #  define __USE_FORTIFY_LEVEL 2
>> -mike
>
>
>
> I have rebuilt the Arch Linux [core] repo (basically software needed for
> boot-up and building more software...) with glibc-2.15-1124-gebc64a1 for
> x86_64.  I get the following issues:
>
>
> A bunch of the afore mentioned gnulib/gets issues (bison, diffutils,
> gettext, gzip, inetutils, libpipeline, m4, man-db, tar, wget)
>
>
> This is a genuine bug in glibc:
> pciutils-3.1.9:
> /usr/include/sys/io.h: In function 'outsw':
> /usr/include/sys/io.h:168:51: error: '____addr' undeclared (first use in
> this function)
> Patch on the way...

I checked in this:

diff --git a/ChangeLog b/ChangeLog
index 49daa0e..4243e52 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2012-06-01  H.J. Lu  <[hidden email]>
+
+ * sysdeps/unix/sysv/linux/x86_64/sys/io.h (outsw): Fix a typo.
+
 2012-06-01  Joseph Myers  <[hidden email]>

  * sysdeps/unix/sysv/linux/powerpc/powerpc32/Makefile
diff --git a/sysdeps/unix/sysv/linux/x86_64/sys/io.h
b/sysdeps/unix/sysv/linux/x86_64/sys/io.h
index 534b6d3..ce9fd94 100644
--- a/sysdeps/unix/sysv/linux/x86_64/sys/io.h
+++ b/sysdeps/unix/sysv/linux/x86_64/sys/io.h
@@ -165,7 +165,7 @@ static __inline void
 outsw (unsigned short int __port, const void *__addr,
        unsigned long int __count)
 {
-  __asm__ __volatile__ ("cld ; rep ; outsw":"=S" (____addr), "=c" (__count)
+  __asm__ __volatile__ ("cld ; rep ; outsw":"=S" (__addr), "=c" (__count)
  :"d" (__port), "0" (__addr), "1" (__count));
 }


>
> I assume these two are missing header issues but have not investigated yet:
>
> busybox-1.19.4:
> shell/shell_common.c: In function 'printlim':
> shell/shell_common.c:369:2: error: unknown type name 'rlim_t'
> shell/shell_common.c:371:13: error: dereferencing pointer to incomplete type
> shell/shell_common.c:373:14: error: dereferencing pointer to incomplete type
> shell/shell_common.c:375:13: error: 'RLIM_INFINITY' undeclared (first
> use in this function)

This is very odd.  Need more info.

> pam-1.1.5:
> pam_unix_acct.c: In function '_unix_run_verify_binary':
> pam_unix_acct.c:97:19: error: storage size of 'rlim' isn't known
> pam_unix_acct.c:106:19: error: 'RLIMIT_NOFILE' undeclared (first use in
> this function)
>

This is very odd.  Need more info.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: v2: The GNU C Library 2.16 release plan

Allan McRae-3
On 02/06/12 10:47, H.J. Lu wrote:
> On Fri, Jun 1, 2012 at 5:36 PM, Allan McRae <[hidden email]> wrote:

>>
>> I assume these two are missing header issues but have not investigated yet:
>>
>> busybox-1.19.4:
>> shell/shell_common.c: In function 'printlim':
>> shell/shell_common.c:369:2: error: unknown type name 'rlim_t'
>> shell/shell_common.c:371:13: error: dereferencing pointer to incomplete type
>> shell/shell_common.c:373:14: error: dereferencing pointer to incomplete type
>> shell/shell_common.c:375:13: error: 'RLIM_INFINITY' undeclared (first
>> use in this function)
>
> This is very odd.  Need more info.
>
>> pam-1.1.5:
>> pam_unix_acct.c: In function '_unix_run_verify_binary':
>> pam_unix_acct.c:97:19: error: storage size of 'rlim' isn't known
>> pam_unix_acct.c:106:19: error: 'RLIMIT_NOFILE' undeclared (first use in
>> this function)
>>
>
> This is very odd.  Need more info.
>

Both these are missing "#include <sys/resource.h>" in the relevant
files.  I guess that was included transitively in glibc-2.15.   So not a
glibc issue.

Allan

12