This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: v2: The GNU C Library 2.16 release plan


On Fri, Jun 1, 2012 at 5:36 PM, Allan McRae <allan@archlinux.org> 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  <hongjiu.lu@intel.com>
+
+	* sysdeps/unix/sysv/linux/x86_64/sys/io.h (outsw): Fix a typo.
+
 2012-06-01  Joseph Myers  <joseph@codesourcery.com>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]