Re: [libvirt] [PATCH] util: fix thinko in runIO

[Peter O'Gorman]

On 11/25/2011 07:38 AM, Eric Blake wrote:

[adding bug-gnulib; replies can drop libvirt]



Providing a posix_memalign_free defeats the purpose - POSIX requires
that plain free() will cover the memory returned by posix_memalign.  The
list of platforms missing posix_memalign is a bit daunting:

MacOS X 10.5, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, Minix 3.1.8, AIX
5.1, HP-UX 11,
IRIX 6.5, OSF/1 5.1, Solaris 10, Cygwin 1.5.x, mingw, MSVC 9, Interix
3.5, BeOS.


Many of these systems have valloc(3) which could be used for this purpose.

Peter

Re: MacOS X 10.7 and gettext

[Peter O'Gorman]

On 10/05/2011 06:54 AM, Bruno Haible wrote:


Interestingly, while MacOS X 10.7 was released on 2011-07-20,
the stpncpy glitch was
   - fixed in MacPorts on 2010-08-13 (these people must have access to
 prereleases of MacOS X or its libc),


This was fixed in MacPorts by Jeremy Huddleston, who, as well as being a 
MacPorts contributor, also happens to be an Apple engineer. So, yes, he 
has "access to prereleases" :-)


Peter

Re: Tru64 dtk vsnprintf module build failure

[Peter O'Gorman]

On Thu, Mar 10, 2011 at 04:26:17PM -0700, Eric Blake wrote:
 
> I'm applying this, after searching for all other modules that ship a .c
> file that includes .


Thanks!

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Tru64 dtk vsnprintf module build failure

[Peter O'Gorman]

Hi,

In the past gnulib-tool --import vsnprintf used to bring in wchar.h, but
it no longer does, so we get this failure on Tru64 5.1:
 cc -DHAVE_CONFIG_H -I. -g -c -MD printf-args.c  -DPIC -o .libs/printf-args.o
cc: Error: /usr/include.dtk/wchar.h, line 78: Ill-formed parameter type list. 
(parmtyplist)
__VA_LIST__ __arg);
^
cc: Error: /usr/include.dtk/wchar.h, line 83: Ill-formed parameter type list. 
(parmtyplist)
__VA_LIST__ __arg);
^
cc: Error: /usr/include.dtk/wchar.h, line 87: Ill-formed parameter type list. 
(parmtyplist)
__VA_LIST__ __arg);
^

This is noted in gnulib's wchar.h replacement - stdio.h must be included
before whcar.h.

We can fix this by adding #include  before the #include
 in printf-args.h, but I'm not sure that it's correct. Gnulib
undoubtedly has many more #include  that may be missing a prior
#include 

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Index: gnulib/printf-args.h
===
--- gnulib/printf-args.h.orig   2011-03-10 22:25:10.0 +
+++ gnulib/printf-args.h2011-03-10 22:30:15.220805277 +
@@ -32,6 +32,13 @@
 /* Get size_t.  */
 #include 
 
+/* Tru64 with Desktop Toolkit C has a bug:  must be included before
+   . */
+
+#ifndef __GLIBC__
+# include 
+#endif
+
 /* Get wchar_t.  */
 #if HAVE_WCHAR_T
 # include 

Re: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX

[Peter O'Gorman]

On Wed, Nov 24, 2010 at 12:07:52PM -0800, Paul Eggert wrote:
> I pushed the following patch; could you please give it a try?
 
> From 531b8a416b6ae40f89808e1db8976eb25972e661 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Wed, 24 Nov 2010 12:05:43 -0800
> Subject: [PATCH] stdint: port to GCC 4.3 + OSX + Octave

> +   int, which would mess up C++ name mangling.  */
> +
> +#if INT64_MAX
> +# define GL_INT64_T
> -typedef unsigned long int gl_uint64_t;

> +#if UINT64_MAX
>  # define GL_UINT64_T
 
Any reason not to #ifdef INT64_MAX/UINT64_MAX instead of plain #if? With
just #if we get preprocessor errors on hpux10.20 with hp cc:

 cc -DHAVE_CONFIG_H -I. -I.. -I./gllib -DASN1_BUILDING -Ae -z +O2 -c
 ASN1.c  +Z -DPIC -o .libs/ASN1.o
cpp: "stdint.h", line 143: warning 2012: Unrepresentable preprocessor
number 9223372036854775807ll.
cpp: "stdint.h", line 143: error 4038: Bad syntax for #if condition.
cpp: "stdint.h", line 166: warning 2012: Unrepresentable preprocessor
number 18446744073709551615ull.
cpp: "stdint.h", line 166: error 4038: Bad syntax for #if condition.

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: Can't build libposix

[Peter O'Gorman]

On 12/11/2010 11:09 PM, Bastien ROUCARIES wrote:

On Sun, Dec 12, 2010 at 10:04 AM, Peter O'Gorman  wrote:

for aix and hpux i have posted some code snipped


hpux code works for me once I change the typo'ed getppid to getpid.

I can't find the AIX code you mention.

Peter

Re: Can't build libposix

[Peter O'Gorman]

On 12/11/2010 06:08 PM, Bastien ROUCARIES wrote:

i have posted some code for hpux and aix to test

under macosx and bsd programname (3) will do the job


I assume you mean getprogname(3) or _NSGetExecutablePath() (see dyld(3)).

This problem was also discussed in 2006 -
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/5080/focus=5082

I had thought it was solved then :/

Peter

Re: test-vc-list-files-cvs.sh failure on OS X 10.6.3

[Peter O'Gorman]

On 05/28/2010 12:30 AM, Gary V. Vaughan wrote:

> Obviously, the test is assuming GNU find (which is called gfind on my
> machine, but it doesn't come with Mac OS, which ships only BSD find),
> but with a cursory look around I couldn't see where the failing find
> was invoked.

It looks for a 'cvsu', hoping to find the one from
http://www.red-bean.com/cvsutils/ but in your case finding cvsu from
http://savannah.gnu.org/projects/cvs-utils

Maybe the test should not look for any cvs-utils at all, since there
appears to be a fallback?

Peter

Re: pwrite module

[Peter O'Gorman]

On Tue, May 18, 2010 at 08:36:28PM +0200, Simon Josefsson wrote:
> The pwrite self-test fails under Cygwin, is this a known issue?

No :)

> 
> http://autobuild.josefsson.org/gnulib/log-201005172227940062000.txt

Hmm, it succeeds writing a byte at (off_t)-1? I guess you end up with a
very large sparse file :)

This chunk of the test I blindly copied from test-pread.c and changed to
pwrite instead. It may be ok that this succeeds, it didn't on the 3
systems I tried it on though (FreeBSD, RHEL, HP-UX10), it failed and set
errno to EINVAL.

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: pwrite module

[Peter O'Gorman]

On Tue, May 11, 2010 at 12:57:20AM +0200, Bruno Haible wrote:
> Hi Peter,
> 
> > Attached. Also noticed that I declare read_buf, but never use it
> 
> Thanks, I applied it, only fixing up the ChangeLog entries (wrong file names).

Oh, bah! Thank you!

> 
> > (good job, really, as it's one byte too short).
> 
> Huh? No, it had the right size. When you call read() with argument N, the
> buffer has to be N bytes large, not N+1.

Yes, the read is ok, but the strcmp would have read past the end of the
buffer, looking for a NULL that I'd never put there.

Doesn't matter though, since I never used read_buf anyway :)

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: pwrite module

[Peter O'Gorman]

On Sat, May 08, 2010 at 10:04:44AM +0200, Bruno Haible wrote:
> Peter O'Gorman wrote:
> > The Written Word, Inc. already has an assignment for gnulib. Look for
> > 'GNULIB  The Written Word' in copyright.list.
> 
> Yes, indeed. It wasn't clear to me whether the patch was owned by you or
> by The Written Word.
> 
> > > - tests/test-pwrite.sh: Removed the pipe, since the test program does not
> > >   access stdin. This file could be removed now, leaving only 
> > > test-pwrite.c.
> 
> Would you like to submit a patch that removes the unnecessary file?

Attached. Also noticed that I declare read_buf, but never use it (good
job, really, as it's one byte too short).

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com
>From 336a9f419541dfb2cf917cded9b486feace10e26 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman 
Date: Mon, 10 May 2010 14:58:57 +
Subject: [PATCH 1/2] Remove useless test-pwrite.sh file.

* test/test-pwrite.sh: Delete file.
* module/pwrite-tests: Remove references.
---
 ChangeLog|6 ++
 modules/pwrite-tests |3 +--
 tests/test-pwrite.sh |7 ---
 3 files changed, 7 insertions(+), 9 deletions(-)
 delete mode 100644 tests/test-pwrite.sh

diff --git a/ChangeLog b/ChangeLog
index 5510f68..03f174e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-05-10  Peter O'Gorman  
+
+   Remove useless test-pwrite.sh file.
+   * test/test-pwrite.sh: Delete file.
+   * module/pwrite-tests: Remove references.
+
 2010-05-10  Jim Meyering  
 
maint.mk: avoid using a temporary file in the always-defined-macros 
check
diff --git a/modules/pwrite-tests b/modules/pwrite-tests
index 6249a8e..5654822 100644
--- a/modules/pwrite-tests
+++ b/modules/pwrite-tests
@@ -1,5 +1,4 @@
 Files:
-tests/test-pwrite.sh
 tests/test-pwrite.c
 tests/init.sh
 tests/signature.h
@@ -10,5 +9,5 @@ Depends-on:
 configure.ac:
 
 Makefile.am:
-TESTS += test-pwrite.sh
+TESTS += test-pwrite
 check_PROGRAMS += test-pwrite
diff --git a/tests/test-pwrite.sh b/tests/test-pwrite.sh
deleted file mode 100644
index 94f0f38..000
--- a/tests/test-pwrite.sh
+++ /dev/null
@@ -1,7 +0,0 @@
-#!/bin/sh
-. "${srcdir=.}/init.sh"; path_prepend_ .
-
-fail=0
-test-pwrite || fail=1
-
-Exit $fail
-- 
1.6.3.3

>From 40c9ad1465f95758743cfafe9454010749e6b2ac Mon Sep 17 00:00:00 2001
From: Peter O'Gorman 
Date: Mon, 10 May 2010 15:02:30 +
Subject: [PATCH 2/2] test-pwrite.c: Remove unused variable declaration.

* test/test-pwrite.c: Remove read_buf declaration.
---
 ChangeLog   |3 +++
 tests/test-pwrite.c |1 -
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 03f174e..fb0804f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 2010-05-10  Peter O'Gorman  
 
+   test-pwrite.c: Remove unused variable declaration.
+   * test/test-pwrite.c: Remove read_buf declaration.
+
Remove useless test-pwrite.sh file.
* test/test-pwrite.sh: Delete file.
* module/pwrite-tests: Remove references.
diff --git a/tests/test-pwrite.c b/tests/test-pwrite.c
index 073f6a3..549be10 100644
--- a/tests/test-pwrite.c
+++ b/tests/test-pwrite.c
@@ -69,7 +69,6 @@ main (void)
   ASSERT (close (fd) == 0);
 
   {
-char read_buf[N];
 fd = open (file, O_RDONLY);
 ASSERT (0 <= fd);
 ASSERT (read (fd, buf, N) == N);
-- 
1.6.3.3

Re: init.sh: enable MALLOC_PERTURB_

[Peter O'Gorman]

On Sun, May 09, 2010 at 10:47:07PM +0200, Jim Meyering wrote:

> +# Enable glibc's malloc-perturbing option.
> +# This is cheap and useful for exposing code that depends on the fact that
> +# malloc-related functions often return memory that is mostly zeroed.
> +# If you have the time and cycles, use valgrind to do an even better job.
> +${MALLOC_PERTURB_=87}
> +export MALLOC_PERTURB_

PASS: test-verify
87: not found
PASS: test-verify.sh

Maybe you want:

: ${MALLOC_PRETURB_=87}


Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: pwrite module

[Peter O'Gorman]

On Wed, May 05, 2010 at 09:43:56PM +0200, Bruno Haible wrote:
> Hi Peter,
> 
> > There is a pread module, but no pwrite. This is a mostly mechanical
> > patch, copying the pread bits and s/read/write/ and copying pwrite.c
> > from glibc.
> 
> Thanks. I committed this in your name.

Thank you for fixing up my attempt at a patch!

> 
> You certainly hate paperwork as much as I do. I don't see a copyright
> assignment for you and gnulib on file so far, only for some autotools
> projects. Would you mind starting the process of a copyright assignment
> for gnulib? You find the form to print in gnulib/doc/Copyright/.

The Written Word, Inc. already has an assignment for gnulib. Look for
'GNULIB  The Written Word' in copyright.list. I may, do the assignment
anyway, since there are sometimes things that come up in my free time
:-)

> - tests/test-pwrite.sh: Removed the pipe, since the test program does not
>   access stdin. This file could be removed now, leaving only test-pwrite.c.
>   What do you think?

I think I didn't think enough about what I was doing :-)

Thanks very much!
Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

pwrite module

[Peter O'Gorman]

Hi,

There is a pread module, but no pwrite. This is a mostly mechanical
patch, copying the pread bits and s/read/write/ and copying pwrite.c
from glibc.

2010-05-05  Peter O'Gorman  

New module pwrite
* doc/posix-functions/pread.texi: Mention gnulib module.
* doc/posix-functions/pwrite.texi: Likewise.
* MODULES.html.sh: Add pwrite.
* lib/unistd.in.h: Likewise.
* m4/unistd_h.m4: Likewise.
* modules/unistd: Likewise.
* tests/test-unistd-c++.cc: Likewise.
* lib/pwrite.c: Likewise.
* m4/pwrite.m4: Likewise.
* modules/pwrite: Likewise.
* modules/pwrite-tests: Likewise.
* tests/test-pwrite.c: Likewise.
* tests/test-pwrite.core: Likewise.
* tests/test-pwrite.sh: Likewise.


Peter
-- 
Peter O'Gorman
po...@thewrittenword.com
>From cd7b12cc394f80b07dc86b5516e2ec5ee934efd8 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman 
Date: Wed, 5 May 2010 02:55:41 +
Subject: [PATCH] New module pwrite

* doc/posix-functions/pread.texi: Mention gnulib module.
* doc/posix-functions/pwrite.texi: Likewise.
* MODULES.html.sh: Add pwrite.
* lib/unistd.in.h: Likewise.
* m4/unistd_h.m4: Likewise.
* modules/unistd: Likewise.
* tests/test-unistd-c++.cc: Likewise.
* lib/pwrite.c: Likewise.
* m4/pwrite.m4: Likewise.
* modules/pwrite: Likewise.
* modules/pwrite-tests: Likewise.
* tests/test-pwrite.c: Likewise.
* tests/test-pwrite.core: Likewise.
* tests/test-pwrite.sh: Likewise.
---
 ChangeLog   |   18 +
 MODULES.html.sh |2 +
 doc/posix-functions/pread.texi  |4 +-
 doc/posix-functions/pwrite.texi |4 +-
 lib/pwrite.c|   64 +++
 lib/unistd.in.h |   36 +-
 m4/pwrite.m4|   18 +
 m4/unistd_h.m4  |8 +++-
 modules/pwrite  |   24 
 modules/pwrite-tests|   14 +++
 modules/unistd  |3 +
 tests/test-pwrite.c |   80 +++
 tests/test-pwrite.sh|7 +++
 tests/test-unistd-c++.cc|5 ++
 14 files changed, 280 insertions(+), 7 deletions(-)
 create mode 100644 lib/pwrite.c
 create mode 100644 m4/pwrite.m4
 create mode 100644 modules/pwrite
 create mode 100644 modules/pwrite-tests
 create mode 100644 tests/test-pwrite.c
 create mode 100755 tests/test-pwrite.sh

diff --git a/ChangeLog b/ChangeLog
index d737948..c3c6e9d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2010-05-05  Peter O'Gorman  
+
+   New module pwrite
+   * doc/posix-functions/pread.texi: Mention gnulib module.
+   * doc/posix-functions/pwrite.texi: Likewise.
+   * MODULES.html.sh: Add pwrite.
+   * lib/unistd.in.h: Likewise. 
+   * m4/unistd_h.m4: Likewise. 
+   * modules/unistd: Likewise. 
+   * tests/test-unistd-c++.cc: Likewise. 
+   * lib/pwrite.c: Likewise. 
+   * m4/pwrite.m4: Likewise. 
+   * modules/pwrite: Likewise. 
+   * modules/pwrite-tests: Likewise. 
+   * tests/test-pwrite.c: Likewise. 
+   * tests/test-pwrite.core: Likewise. 
+   * tests/test-pwrite.sh: Likewise. 
+
 2010-05-04  Eric Blake  
 
docs: update cygwin progress
diff --git a/MODULES.html.sh b/MODULES.html.sh
index b0fbe39..822ac83 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -846,6 +846,7 @@ pow
 powf
 powl
 pread
+pwrite
 printf
 pselect
 psiginfo
@@ -1346,6 +1347,7 @@ index
 makecontext
 mktemp
 pread
+pwrite
 pthread_attr_getstackaddr
 pthread_attr_setstackaddr
 rindex
diff --git a/doc/posix-functions/pread.texi b/doc/posix-functions/pread.texi
index a11e36e..651256d 100644
--- a/doc/posix-functions/pread.texi
+++ b/doc/posix-functions/pread.texi
@@ -4,13 +4,13 @@
 
 POSIX specification: 
@url{http://www.opengroup.org/onlinepubs/9699919799/functions/pread.html}
 
-Gnulib module: ---
+Gnulib module: pread 
 
 Portability problems fixed by Gnulib:
 @itemize
 @item
 This function is missing on some platforms:
-mingw, BeOS.
+mingw, BeOS, HP-UX 10.
 @end itemize
 
 Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/pwrite.texi b/doc/posix-functions/pwrite.texi
index d164503..735c897 100644
--- a/doc/posix-functions/pwrite.texi
+++ b/doc/posix-functions/pwrite.texi
@@ -4,7 +4,7 @@
 
 POSIX specification: 
@url{http://www.opengroup.org/onlinepubs/9699919799/functions/pwrite.html}
 
-Gnulib module: ---
+Gnulib module: pwrite 
 
 Portability problems fixed by Gnulib:
 @itemize
@@ -14,5 +14,5 @@ Portability problems not fixed by Gnulib:
 @itemize
 @item
 This function is missing on some platforms:
-mingw, BeOS.
+mingw, BeOS, HP-UX 10.
 @end itemize
diff --git a/lib/pwrite.c b/lib/pwrite.c
new file mode 100644
index 000..f9c1498
--- /dev/null
+++ b/lib/pwrite.c
@@ -0,0 +1,64 @@
+/* Write block to given position in file without changing file
+ * poi

Re: support for universal binaries on MacOS X (5/6)

[Peter O'Gorman]

Bruno Haible wrote:
> Jim,
> 
> The configure test whether mktime works produces the result "yes" in 32-bit
> mode and "no" in 64-bit mode. In universal builds, we cannot manage these
> different results (it would become a #ifdef mess). Therefore I propose to
> combine the results to "no". OK to commit?
> 

This is surprising, what is the reason for the 64 bit failure?

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)

[Peter O'Gorman]

Jim Meyering wrote:
> Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> 
>> Eric Blake wrote:
>>> According to Jim Meyering on 9/16/2008 3:58 AM:
>>>> Jim Meyering <[EMAIL PROTECTED]> wrote:
>>>>> I discovered that Solaris 11's /bin/sh exhibits the following
>>>>> surprising behavior:
>>>>>
>>>>> $ /bin/sh -c 'umask 22; (umask 0); umask'
>>>>> 
>>> We should also document this in the autoconf manual.
>>>
>> Has it been reported? Seems like the kind of thing that could be fixed
>> before Solaris 11 is released.
>>
>> http://defect.opensolaris.org/
> 
> Thanks for the link.  I've just filed a report:
> 
> http://defect.opensolaris.org/bz/show_bug.cgi?id=3450

Ugh, I should have tried it before telling you to report it:
% uname -a
SunOS XX 5.11 snv_91 i86pc i386 i86pc
% /bin/sh -c 'umask 22; (umask 0); umask'
0022

Looks like this bug is already fixed somewhere between builds 86 and 91.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)

[Peter O'Gorman]

Eric Blake wrote:
> According to Jim Meyering on 9/16/2008 3:58 AM:
>> Jim Meyering <[EMAIL PROTECTED]> wrote:
>>> I discovered that Solaris 11's /bin/sh exhibits the following
>>> surprising behavior:
>>>
>>> $ /bin/sh -c 'umask 22; (umask 0); umask'
>>> 
> 
> We should also document this in the autoconf manual.
> 

Has it been reported? Seems like the kind of thing that could be fixed
before Solaris 11 is released.

http://defect.opensolaris.org/

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: inline related build failures on MacOS X 10.5

[Peter O'Gorman]

Bruno Haible wrote:
> Ludovic Courtès wrote:
>> FWIW, I solved it this way in Guile, based on what GNU R does:
>>
>>   
>> http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c
> 
> Do you have information about the compilers with build numbers 5401..5464 ?
> 
> Btw, when the next version of Apple gcc comes out, based on gcc >= 4.3, and
> defines __GNUC_STDC_INLINE__, this code will still use 'static inline'.

It is unlikely that there will be a version of gcc from Apple based on
gcc-4.3 or later (because Apple is currently not introducing any GPLv3
software).

http://www.opensource.apple.com/darwinsource/10.5/
gcc-5465 is the first publicly released version of gcc-4.0.1 from Apple
with this feature.

Note that what will become Xcode-3.1 seems to have this fixed:
http://www.opensource.apple.com/darwinsource/iPhoneSDKBeta3/gcc-5479/gcc/c-cppbuiltin.c
compare to:
http://www.opensource.apple.com/darwinsource/10.5/gcc-5465/gcc/c-cppbuiltin.c

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Tue, Mar 11, 2008 at 05:44:12AM +0100, Bruno Haible wrote:
> Peter O'Gorman wrote:
> > Attached.
> 
> Thanks. I have applied this modified patch.

Thank you!

Peter 

Re: AIX 5.1 xlc va_copy (stdarg patch) *ping*

[Peter O'Gorman]

ping?

http://lists.gnu.org/archive/html/bug-gnulib/2008-02/msg00148.html

Peter

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Wed, Feb 27, 2008 at 09:13:06AM -0600, Peter O'Gorman wrote:
 
> Ok. Will do this later.

Attached.

Peter
diff --git a/doc/posix-functions/va_copy.texi b/doc/posix-functions/va_copy.texi
index c5a012b..a2ce0e3 100644
--- a/doc/posix-functions/va_copy.texi
+++ b/doc/posix-functions/va_copy.texi
@@ -10,6 +10,13 @@ Portability problems fixed by Gnulib:
 @itemize
 @item
 This macro is missing on some platforms.
[EMAIL PROTECTED]
+On some platforms va_copy is available as __va_copy and so needs to be
+defined as such.
[EMAIL PROTECTED]
+On AIX systems with xlc, the @code{-qlanglvl=extc99} or
[EMAIL PROTECTED] is normally required for va_copy to be
+defined. This module makes it available even without that flag.
 @end itemize
 
 Portability problems not fixed by Gnulib:
diff --git a/m4/stdarg.m4 b/m4/stdarg.m4
index e8e680a..db69478 100644
--- a/m4/stdarg.m4
+++ b/m4/stdarg.m4
@@ -9,6 +9,8 @@ dnl Provide a working va_copy in combination with .
 
 AC_DEFUN([gl_STDARG_H],
 [
+  STDARG_H=
+  AC_SUBST([STDARG_H])
   AC_MSG_CHECKING([for va_copy])
   AC_CACHE_VAL([gl_cv_func_va_copy], [
 AC_TRY_COMPILE([#include ], [
@@ -31,10 +33,25 @@ error, bail out
   AC_DEFINE([va_copy], [__va_copy],
 [Define as a macro for copying va_list variables.])
 else
+  AC_LANG_PUSH(C)
+  AC_COMPILE_IFELSE(AC_LANG_PROGRAM([#if defined _AIX && ! defined __GNUC__
+choke me
+#endif],[]),[
   AH_VERBATIM([gl_VA_COPY], [/* A replacement for va_copy, if needed.  */
 #define gl_va_copy(a,b) ((a) = (b))])
   AC_DEFINE([va_copy], [gl_va_copy],
 [Define as a macro for copying va_list variables.])
+],[
+  STDARG_H=stdarg.h
+  gl_CHECK_NEXT_HEADERS([stdarg.h])
+  # Above will not work on systems that do not have #include_next
+  # because stdarg.h has only macros. Fix this below. 
+  if test "x$gl_cv_next_stdarg_h" = "x\"\""; then
+gl_cv_next_stdarg_h=\"///usr/include/stdarg.h\"
+NEXT_STDARG_H="$gl_cv_next_stdarg_h"
+  fi
+])
+  AC_LANG_POP(C)
 fi
   fi
 ])
diff --git a/modules/stdarg b/modules/stdarg
index 48febb2..e386f3e 100644
--- a/modules/stdarg
+++ b/modules/stdarg
@@ -3,8 +3,10 @@ An  that conforms to C99.
 
 Files:
 m4/stdarg.m4
+lib/stdarg.in.h
 
 Depends-on:
+include_next
 
 configure.ac-early:
 dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
@@ -17,6 +19,21 @@ configure.ac:
 gl_STDARG_H
 
 Makefile.am:
+BUILT_SOURCES += $(STDARG_H)
+
+# We need the following in order to create  when the system
+# doesn't have one that works with the given compiler.
+stdarg.h: stdarg.in.h
+   rm -f [EMAIL PROTECTED] $@
+   { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+   sed -e 's/@''INCLUDE_NEXT''@/$(INCLUDE_NEXT)/g' \
+   -e 's|@''NEXT_STDARG_H''@|$(NEXT_STDARG_H)|g' \
+   -e 's/@''HAVE_VA_COPY''@/$(HAVE_VA_COPY)/g' \
+   < $(srcdir)/stdarg.in.h; \
+   } > [EMAIL PROTECTED]
+   mv [EMAIL PROTECTED] $@
+
+MOSTLYCLEANFILES += stdarg.h stdarg.h-t
 
 Include:
 #include 
--- /dev/null   Wed Feb 27 07:11:00 2008
+++ a/lib/stdarg.in.h   Tue Feb 26 21:18:57 2008
@@ -0,0 +1,31 @@
+/* 
+   Copyright (C) 2008 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License along
+   with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _GL_STDARG_H
+
+/* The include_next requires a split double-inclusion guard.  */
[EMAIL PROTECTED]@ @NEXT_STDARG_H@
+
+#ifndef _GL_STDARG_H
+#define _GL_STDARG_H
+
+#ifndef va_copy
+#define va_copy(a,b) ((a) = (b))
+#endif
+
+#endif /* _GL_STDARG_H */
+#endif /* _GL_STDARG_H */

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Wed, Feb 27, 2008 at 12:35:56PM +0100, Bruno Haible wrote:
> Peter O'Gorman wrote:
> This is too risky. This approach is very likely to break platforms other
> than AIX.
> 

Sigh. Ok.

> We have an  replacement that works well everywhere except your
> particular version of AIX 5.1. The particular problem, as you said in
> your first mail, is that  or  on this system does
> a "#undef va_copy". (You said , but your patch looks like you
> meant ?)

Yes, I meant stdarg.

> On the AIX 5.1 I have access to, /usr/include/stddef.h
> and /usr/include/stdarg.h don't mention va_copy, i.e. don't undef them
> either.

/usr/vac/include/stdarg.h - the compiler's version.

> 
> Please restrict the effects of your patch to AIX without GNU C. This is
> what you are able to test.

Ok. Will do this later.

Peter

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Wed, Feb 27, 2008 at 05:03:01AM +0100, Bruno Haible wrote:

> Instead, how about generating the stdarg.h replacement only for
>   defined _AIX && !defined __GNUC__
> and letting it look like this:
> 
> #ifndef _GL_STDARG_H
> #include "/usr/include/stdarg.h"
> #ifndef va_copy
> #define va_copy(a,b) ((a) = (b))
> #endif
> #endif
> 
> It should be safe to assume that for non-GNU compilers on AIX the 
> is in /usr/include.

I am not sure that I agree.

Since this problem will only exist on compilers and systems without
va_copy, __va_copy and #include_next, I think it is probably a safe
bet to hardcode ///usr/include/stdarg.h on all such systems.

The only system that we have that does not have #include_next with
the native compiler is aix4.3.3 with xlc. Even there #include_next is
available with -qlanglvl=extc89, or simply invoking the compiler with
cc rather than xlc.

This patch hardcodes ///usr/include/stdarg.h if the system does not
have #include_next, va_copy or __va_copy.

Peter 
diff --git a/doc/posix-functions/va_copy.texi b/doc/posix-functions/va_copy.texi
index c5a012b..a2ce0e3 100644
--- a/doc/posix-functions/va_copy.texi
+++ b/doc/posix-functions/va_copy.texi
@@ -10,6 +10,13 @@ Portability problems fixed by Gnulib:
 @itemize
 @item
 This macro is missing on some platforms.
[EMAIL PROTECTED]
+On some platforms va_copy is available as __va_copy and so needs to be
+defined as such.
[EMAIL PROTECTED]
+On AIX systems with xlc, the @code{-qlanglvl=extc99} or
[EMAIL PROTECTED] is normally required for va_copy to be
+defined. This module makes it available even without that flag.
 @end itemize
 
 Portability problems not fixed by Gnulib:
index e8e680a..1040df7 100644
--- a/m4/stdarg.m4
+++ b/m4/stdarg.m4
@@ -9,6 +9,10 @@ dnl Provide a working va_copy in combination with .
 
 AC_DEFUN([gl_STDARG_H],
 [
+  HAVE_VA_COPY=1
+  STDARG_H=
+  AC_SUBST([STDARG_H])
+  AC_SUBST([HAVE_VA_COPY])
   AC_MSG_CHECKING([for va_copy])
   AC_CACHE_VAL([gl_cv_func_va_copy], [
 AC_TRY_COMPILE([#include ], [
@@ -31,10 +35,13 @@ error, bail out
   AC_DEFINE([va_copy], [__va_copy],
 [Define as a macro for copying va_list variables.])
 else
-  AH_VERBATIM([gl_VA_COPY], [/* A replacement for va_copy, if needed.  */
-#define gl_va_copy(a,b) ((a) = (b))])
-  AC_DEFINE([va_copy], [gl_va_copy],
-[Define as a macro for copying va_list variables.])
+  STDARG_H=stdarg.h
+  HAVE_VA_COPY=0
+  gl_CHECK_NEXT_HEADERS([stdarg.h])
+  if test "x$gl_cv_next_stdarg_h" = "x\"\""; then
+gl_cv_next_stdarg_h=\"///usr/include/stdarg.h\"
+NEXT_STDARG_H=\"///usr/include/stdarg.h\"
+  fi
 fi
   fi
 ])
diff --git a/modules/stdarg b/modules/stdarg
index 48febb2..e386f3e 100644
--- a/modules/stdarg
+++ b/modules/stdarg
@@ -3,8 +3,10 @@ An  that conforms to C99.
 
 Files:
 m4/stdarg.m4
+lib/stdarg.in.h
 
 Depends-on:
+include_next
 
 configure.ac-early:
 dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
@@ -17,6 +19,21 @@ configure.ac:
 gl_STDARG_H
 
 Makefile.am:
+BUILT_SOURCES += $(STDARG_H)
+
+# We need the following in order to create  when the system
+# doesn't have one that works with the given compiler.
+stdarg.h: stdarg.in.h
+   rm -f [EMAIL PROTECTED] $@
+   { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+   sed -e 's/@''INCLUDE_NEXT''@/$(INCLUDE_NEXT)/g' \
+   -e 's|@''NEXT_STDARG_H''@|$(NEXT_STDARG_H)|g' \
+   -e 's/@''HAVE_VA_COPY''@/$(HAVE_VA_COPY)/g' \
+   < $(srcdir)/stdarg.in.h; \
+   } > [EMAIL PROTECTED]
+   mv [EMAIL PROTECTED] $@
+
+MOSTLYCLEANFILES += stdarg.h stdarg.h-t
 
 Include:
 #include 
--- /dev/null   Wed Feb 27 07:11:00 2008
+++ a/lib/stdarg.in.h   Tue Feb 26 21:18:57 2008
@@ -0,0 +1,31 @@
+/* 
+   Copyright (C) 2008 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License along
+   with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _GL_STDARG_H
+
+/* The include_next requires a split double-inclusion guard.  */
[EMAIL PROTECTED]@ @NEXT_STDARG_H@
+
+#ifndef _GL_STDARG_H
+#define _GL_STDARG_H
+
+#ifndef va_copy
+#define va_copy(a,b) ((a) = (b))
+#endif
+
+#endif /* _GL_STDARG_H */
+#endif /* _GL_STDARG_H */

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Tue, Feb 26, 2008 at 06:06:06PM -0600, Peter O'Gorman wrote:
> > After all, if there is already a va_copy, and it disagrees with our
> > substitute, we're probably wrong.  Doing this removes the need for
> > generating or substituting HAVE_VA_COPY.  va_copy is required to be a
> > macro, so this should be safe.
> >
> 
> Yes, it would be simpler and I would have done that had it even
> crossed my mind :)
>

Looks like this breaks on AIX 4.3.3 :(

gl_CHECK_NEXT_HEADERS fails to find the absolute file name for
stddef.h, it finds the empty string and substitutes

#include ""

into the generated stdarg.h

It looks like gl_CHECK_NEXT_HEADERS fails for headers that do not
declare any functions. stdarg.h only defines macros :(

Peter 

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Tue, Feb 26, 2008 at 03:46:15PM -0800, Paul Eggert wrote:
> "Peter O'Gorman" <[EMAIL PROTECTED]> writes:
> 
> > +#if ! @HAVE_VA_COPY@
> > +#define va_copy(a,b) ((a) = (b))
> > +#endif
> 
> Wouldn't it be simpler to do this?
> 
> #ifndef va_copy
> #define va_copy(a,b) ((a) = (b))
> #endif
> 
> After all, if there is already a va_copy, and it disagrees with our
> substitute, we're probably wrong.  Doing this removes the need for
> generating or substituting HAVE_VA_COPY.  va_copy is required to be a
> macro, so this should be safe.
>

Yes, it would be simpler and I would have done that had it even
crossed my mind :)

Peter 

Re: AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

On Tue, Feb 26, 2008 at 04:54:16PM -0600, Peter O'Gorman wrote:

> diff --git a/m4/stdarg.m4 b/m4/stdarg.m4
> index e8e680a..36af1ad 100644
> --- a/m4/stdarg.m4
> +++ b/m4/stdarg.m4

> --- a/modules/stdarg
> +++ b/modules/stdarg

> --- /dev/null Tue Feb 26 22:22:00 2008
> +++ lib/stdarg.in.h   Tue Feb 26 21:16:02 2008

Sigh, last hunk is not going to apply, doh!

I changed to +++ a/lib/stdarg.in.h in this version.

Peter
2008-??-??  Peter O'Gorman  <[EMAIL PROTECTED]>

* modules/stdarg: Use a replacement header for va_copy.
* lib/stdarg.in.h: This is it.
* m4/stdarg.m4: Use the replacement header if va_copy and
__va_copy are not available.

diff --git a/m4/stdarg.m4 b/m4/stdarg.m4
index e8e680a..36af1ad 100644
--- a/m4/stdarg.m4
+++ b/m4/stdarg.m4
@@ -9,6 +9,10 @@ dnl Provide a working va_copy in combination with .
 
 AC_DEFUN([gl_STDARG_H],
 [
+  HAVE_VA_COPY=1
+  STDARG_H=
+  AC_SUBST([STDARG_H])
+  AC_SUBST([HAVE_VA_COPY])
   AC_MSG_CHECKING([for va_copy])
   AC_CACHE_VAL([gl_cv_func_va_copy], [
 AC_TRY_COMPILE([#include ], [
@@ -31,10 +35,9 @@ error, bail out
   AC_DEFINE([va_copy], [__va_copy],
 [Define as a macro for copying va_list variables.])
 else
-  AH_VERBATIM([gl_VA_COPY], [/* A replacement for va_copy, if needed.  */
-#define gl_va_copy(a,b) ((a) = (b))])
-  AC_DEFINE([va_copy], [gl_va_copy],
-[Define as a macro for copying va_list variables.])
+  STDARG_H=stdarg.h
+  HAVE_VA_COPY=0
+  gl_CHECK_NEXT_HEADERS([stdarg.h])
 fi
   fi
 ])
diff --git a/modules/stdarg b/modules/stdarg
index 48febb2..e386f3e 100644
--- a/modules/stdarg
+++ b/modules/stdarg
@@ -3,8 +3,10 @@ An  that conforms to C99.
 
 Files:
 m4/stdarg.m4
+lib/stdarg.in.h
 
 Depends-on:
+include_next
 
 configure.ac-early:
 dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
@@ -17,6 +19,21 @@ configure.ac:
 gl_STDARG_H
 
 Makefile.am:
+BUILT_SOURCES += $(STDARG_H)
+
+# We need the following in order to create  when the system
+# doesn't have one that works with the given compiler.
+stdarg.h: stdarg.in.h
+   rm -f [EMAIL PROTECTED] $@
+   { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+   sed -e 's/@''INCLUDE_NEXT''@/$(INCLUDE_NEXT)/g' \
+   -e 's|@''NEXT_STDARG_H''@|$(NEXT_STDARG_H)|g' \
+   -e 's/@''HAVE_VA_COPY''@/$(HAVE_VA_COPY)/g' \
+   < $(srcdir)/stdarg.in.h; \
+   } > [EMAIL PROTECTED]
+   mv [EMAIL PROTECTED] $@
+
+MOSTLYCLEANFILES += stdarg.h stdarg.h-t
 
 Include:
 #include 
--- /dev/null   Tue Feb 26 22:22:00 2008
+++ a/lib/stdarg.in.h   Tue Feb 26 21:16:02 2008
@@ -0,0 +1,31 @@
+/* 
+   Copyright (C) 2008 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License along
+   with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _GL_STDARG_H
+
+/* The include_next requires a split double-inclusion guard.  */
[EMAIL PROTECTED]@ @NEXT_STDARG_H@
+
+#ifndef _GL_STDARG_H
+#define _GL_STDARG_H
+
+#if ! @HAVE_VA_COPY@
+#define va_copy(a,b) ((a) = (b))
+#endif
+
+#endif /* _GL_STDARG_H */
+#endif /* _GL_STDARG_H */

AIX 5.1 xlc va_copy (stdarg patch)

[Peter O'Gorman]

Hi,

We could not build GnuTLS-2.2.2 on AIX-5.1 in 64 bit mode because
va_copy requires -qlanglvl=extc99, however, with that flag compilation
failed (and many warnings were issued).

The warnings were like:
1506-784 (W) Decimal integer constant "18446744073709551615" is out of range
for any use of ULONG_MAX.

Finally it errored out in minilzo when it saw this:
#if (USHRT_MAX < 1) || (UINT_MAX < 1) || (ULONG_MAX < 1)
#  error "your limits.h macros are broken"
#endif

I could not find an xlc flag that I could add to -qlanglvl=extc99 to
make these warnings and errors go away.

Removing -qlanglvl=extc99 resulted in undefined symbols for va_copy.

Turns out that even though config.h correctly has '#define va_copy
gl_va_copy', xlc's stddef.h #undefs va_copy and does not define it to
the builtin.

xlc's stdarg.h also does not have any include guards, so you can not
#include  then #define va_copy, as the next time stdarg.h
gets included it will get undefined all over again.

This patch allows us to build GnuTLS on AIX 5.1 without any -qlanglvl
flags.

Thanks,
Peter
2008-??-??  Peter O'Gorman  <[EMAIL PROTECTED]>

* modules/stdarg: Use a replacement header for va_copy.
* lib/stdarg.in.h: This is it.
* m4/stdarg.m4: Use the replacement header if va_copy and
__va_copy are not available.

diff --git a/m4/stdarg.m4 b/m4/stdarg.m4
index e8e680a..36af1ad 100644
--- a/m4/stdarg.m4
+++ b/m4/stdarg.m4
@@ -9,6 +9,10 @@ dnl Provide a working va_copy in combination with .
 
 AC_DEFUN([gl_STDARG_H],
 [
+  HAVE_VA_COPY=1
+  STDARG_H=
+  AC_SUBST([STDARG_H])
+  AC_SUBST([HAVE_VA_COPY])
   AC_MSG_CHECKING([for va_copy])
   AC_CACHE_VAL([gl_cv_func_va_copy], [
 AC_TRY_COMPILE([#include ], [
@@ -31,10 +35,9 @@ error, bail out
   AC_DEFINE([va_copy], [__va_copy],
 [Define as a macro for copying va_list variables.])
 else
-  AH_VERBATIM([gl_VA_COPY], [/* A replacement for va_copy, if needed.  */
-#define gl_va_copy(a,b) ((a) = (b))])
-  AC_DEFINE([va_copy], [gl_va_copy],
-[Define as a macro for copying va_list variables.])
+  STDARG_H=stdarg.h
+  HAVE_VA_COPY=0
+  gl_CHECK_NEXT_HEADERS([stdarg.h])
 fi
   fi
 ])
diff --git a/modules/stdarg b/modules/stdarg
index 48febb2..e386f3e 100644
--- a/modules/stdarg
+++ b/modules/stdarg
@@ -3,8 +3,10 @@ An  that conforms to C99.
 
 Files:
 m4/stdarg.m4
+lib/stdarg.in.h
 
 Depends-on:
+include_next
 
 configure.ac-early:
 dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
@@ -17,6 +19,21 @@ configure.ac:
 gl_STDARG_H
 
 Makefile.am:
+BUILT_SOURCES += $(STDARG_H)
+
+# We need the following in order to create  when the system
+# doesn't have one that works with the given compiler.
+stdarg.h: stdarg.in.h
+   rm -f [EMAIL PROTECTED] $@
+   { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+   sed -e 's/@''INCLUDE_NEXT''@/$(INCLUDE_NEXT)/g' \
+   -e 's|@''NEXT_STDARG_H''@|$(NEXT_STDARG_H)|g' \
+   -e 's/@''HAVE_VA_COPY''@/$(HAVE_VA_COPY)/g' \
+   < $(srcdir)/stdarg.in.h; \
+   } > [EMAIL PROTECTED]
+   mv [EMAIL PROTECTED] $@
+
+MOSTLYCLEANFILES += stdarg.h stdarg.h-t
 
 Include:
 #include 
--- /dev/null   Tue Feb 26 22:22:00 2008
+++ lib/stdarg.in.h Tue Feb 26 21:16:02 2008
@@ -0,0 +1,31 @@
+/* 
+   Copyright (C) 2008 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License along
+   with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _GL_STDARG_H
+
+/* The include_next requires a split double-inclusion guard.  */
[EMAIL PROTECTED]@ @NEXT_STDARG_H@
+
+#ifndef _GL_STDARG_H
+#define _GL_STDARG_H
+
+#if ! @HAVE_VA_COPY@
+#define va_copy(a,b) ((a) = (b))
+#endif
+
+#endif /* _GL_STDARG_H */
+#endif /* _GL_STDARG_H */

Re: environ on MacOS X

[Peter O'Gorman]

Bruno Haible wrote:
> Peter O'Gorman wrote:
>> glibtool --mode=link gcc -o libfoo.la fooshared.lo
> 
> And does the executable that you create by linking against this library
> work on MacOS X 10.5? It works on 10.3.

Yes, it works.

Thank you,
Peter
-- 
Peter O'Gorman
http://pogma.com

Re: time_r.m4 checks unexpectedly pass on hpux10

[Peter O'Gorman]

Bruno Haible wrote:

>> The compile line and warning:
>> cc -Ae -c lcltimecheck.c -D_REENTRANT 
>> cc: "lcltimecheck.c", line 7: warning 604: Pointers are not 
>> assignment-compatible.
> 
> Thanks for reporting this.

> How about this proposed patch? Does it work for you?

This worked. Thank you.

Peter

Re: environ on MacOS X

[Peter O'Gorman]

Bruno Haible wrote:
> Peter O'Gorman wrote:
>> crt_externs.h and _NSGetEnviron works on all released versions of Mac OS X.
> 
> Thanks for this info. I'm updating the doc (see below).
> 
>> The environ symbol is available to every application, it is in the c
>> startup object crt1.o (on 10.5 crt1.10.5.o), but the static linker, when
>> set to not allow any undefined symbols (the default) does not know about
>> it when creating a shared library (because crt1.0 is only added when
>> creating an executable), so linking will fail with undefined references
>> to _environ in that case.
>>
>> A library which allows undefined symbols (the GNU libtool default) will
>> not see this problem.
> 
> Well, there must be something different between MacOS X 10.[34] and 10.5.
> The cited references mention a problem that cropped up with 10.5, not
> earlier.
> 
> Attached you find the test script that I used to verify that both declarations
> work on 10.3. (I cannot test 10.4 or 10.5.)

It is an old problem, e.g.
http://lists.apple.com/archives/Darwin-development/2003/Apr/msg00177.html

Here is me compiling your test on Mac OS X 10.5 (using the systems GNU
libtool 1.5.22):

mb:environs peter$ cat fooshared.c
#if 1
extern char **environ;
#else
#include 
#define environ (*_NSGetEnviron())
#endif
char *** environ_addr (void) { return &environ; }
mb:environs peter$ glibtool --mode=compile gcc -c fooshared.c
 gcc -c fooshared.c  -fno-common -DPIC -o .libs/fooshared.o
 gcc -c fooshared.c -o fooshared.o >/dev/null 2>&1
mb:environs peter$ glibtool --mode=link gcc -o libfoo.la fooshared.lo
-rpath /no
texist
rm -fr  .libs/libfoo.0.0.0.dylib .libs/libfoo.0.dylib .libs/libfoo.a
.libs/libfo
o.dylib .libs/libfoo.la .libs/libfoo.lai
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
.libs/libfoo.0.0.0.dylib
 .libs/fooshared.o   -install_name  /notexist/libfoo.0.dylib
-Wl,-compatibility_
version -Wl,1 -Wl,-current_version -Wl,1.0
(cd .libs && rm -f libfoo.0.dylib && ln -s libfoo.0.0.0.dylib
libfoo.0.dylib)
(cd .libs && rm -f libfoo.dylib && ln -s libfoo.0.0.0.dylib libfoo.dylib)
ar cru .libs/libfoo.a  fooshared.o
ranlib .libs/libfoo.a
creating libfoo.la
(cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)
mb:environs peter$ glibtool --mode=link gcc -o libfoo.la fooshared.lo
-rpath /no
texist -no-undefined
rm -fr  .libs/libfoo.0.0.0.dylib .libs/libfoo.0.dylib .libs/libfoo.a
.libs/libfo
o.dylib .libs/libfoo.la .libs/libfoo.lai
gcc -dynamiclib  -o .libs/libfoo.0.0.0.dylib  .libs/fooshared.o
-install_name
 /notexist/libfoo.0.dylib -Wl,-compatibility_version -Wl,1
-Wl,-current_version
-Wl,1.0
Undefined symbols:
  "_environ", referenced from:
  _environ$non_lazy_ptr in fooshared.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: environ on MacOS X

[Peter O'Gorman]

Bruno Haible wrote:

> 
> 2008-02-24  Bruno Haible  <[EMAIL PROTECTED]>
> 
>   * doc/posix-functions/environ.texi: Document the MacOS X problem.
> 
> *** doc/posix-functions/environ.texi.orig 2008-02-24 15:26:50.0 
> +0100
> --- doc/posix-functions/environ.texi  2008-02-24 15:25:16.0 +0100
> ***
> *** 16,21 
> --- 16,33 
>   This variable is missing on some platforms:
>   MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, IRIX 6.5, OSF/1 5.1, 
> Cygwin.
>   @item
> + On MacOS X 10, this variable is not declared.  Up to MacOS X 10.4, one can 
> use
> + @smallexample
> + extern char **environ;
> + @end smallexample
> + to get the variable declared.  This does not work any more, however, in
> + shared libraries on MacOS X 10.5.  Here is a workaround: Instead, one can 
> use
> + @smallexample
> + #include 
> + #define environ (*_NSGetEnviron())
> + @end smallexample
> + This works at least on MacOS X 10.3 and newer.


Hi Bruno,

crt_externs.h and _NSGetEnviron works on all released versions of Mac OS X.

The environ symbol is available to every application, it is in the c
startup object crt1.o (on 10.5 crt1.10.5.o), but the static linker, when
set to not allow any undefined symbols (the default) does not know about
it when creating a shared library (because crt1.0 is only added when
creating an executable), so linking will fail with undefined references
to _environ in that case.

A library which allows undefined symbols (the GNU libtool default) will
not see this problem.

Thanks for writing this up, it is good to have the crt_externs.h
solution in the docs.

Peter
-- 
Peter O'Gorman
http://pogma.com

time_r.m4 checks unexpectedly pass on hpux10

[Peter O'Gorman]

Hi,

HP-UX10 has:
int gmtime_r(const time_t *timer, struct tm *result);
int localtime_r(const time_t *timer, struct tm *result);

Which is, as you know, not standards conforming.

However, compiling the test case for reentrant time functions on
hpux10 with its native cc and -Ae results in a compiler warning, not
an error. So the test, unfortunately, passes.

The test case is:
#include 

int main() {
/* We don't need to append 'restrict's to the argument types,
   even though the POSIX signature has the 'restrict's,   
   since C99 says they can't affect type compatibility.  */
   struct tm * (*ptr) (time_t const *, struct tm *) = localtime_r;
   if (ptr) return 0;
}

The compile line and warning:
cc -Ae -c lcltimecheck.c -D_REENTRANT 
cc: "lcltimecheck.c", line 7: warning 604: Pointers are not 
assignment-compatible.

Perhaps we should set ac_c_werror_flag=yes before running this test?

Thanks,
Peter

Re: getloadavg on aix5

[Peter O'Gorman]

Jim Meyering wrote:
> "Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
>> I seem to have lost Jim's reply, but here is a patch. Works on
>> aix-4.3.3 and aix-5.3.
>>
>> The SBITS thing is the way the libperstat.h header recommends
>> calculating the loadavg:
>>
>> /* To calculate the load average, divide the numbers by (1<> defined in . */
>>
>> Of course, it is not defined on aix4.3.3 ...
> 
> Hi Peter,
> 
> Here's an incremental diff.
> Most changes are syntactic, but I did eliminate an #if block
> by moving the static declaration of cpu_stats into the
> block that uses that variable.  I also removed some casts.
> 
> FYI, I realize you were just retaining the existing style,
> but I'd rather begin the process of moving toward less
> syntax (removing parentheses around cpp symbols), at least
> on most of the lines touched by this change.
> 
> If you can confirm that this works, I'll write
> the ChangeLog and check in the combined change set.

This works (tested on aix4.3.3, aix5.1, 5.2 and 5.3).

I suppose a possible ChangeLog would be:

2008-02-05  Peter O'Gorman <[EMAIL PROTECTED]>,
Jim Meyering <[EMAIL PROTECTED]>
* lib/getloadavg.c, m4/getloadavg.m4 [aix]: Use libperfstat.

Thank you,
Peter

Re: config.guess and $CC

[Peter O'Gorman]

James Youngman wrote:

> Maybe to save diagnostic effort in other quarters we should issue a
> warning for the benefit of maintainers when we're overriding the
> output of "uname -m".  One could hope that such warning messages would
> get included in people's bug reports.  There is an argument for even
> issuing a warning of a plan to change the behaviour without actually
> channging it yet.  Unfortunately though, the percolation time on new
> versions of config.guess is so long that we'd essentially be making
> life hard for lots of users for quite a long time, in order to avoid
> making life hard for a smaller number of maintainers for less time.

I realize that it makes sense to have config.guess return
x86_64-apple-darwin and ppc64-apple-darwin etc, and if such a change is
implemented there will be no need to print a warning because - it makes
sense.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: config.guess and $CC

[Peter O'Gorman]

Bruno Haible wrote:

> Yes. And a new platform x86_64*darwin* has appeared. People who have
> configure scripts that check only for known platforms obviously have to
> make adjustments when new platforms appear. New platforms have been
> appearing constantly for the past 15 years.

I have a hard time accepting that a machine that people have been
building free software on for over a year and a half (64 bit intel mac)
is a new platform, or a machine that people have been creating fat
binaries on for 7 years is a new platform.

I believe that any such change to config.guess will do more harm than good.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: frexpl bugs remain on OS X 10.5 intel

[Peter O'Gorman]

Gary V. Vaughan wrote:
> I'm not passing any special flags, so whatever is standard for the apple
> shipped
> build of gcc on 10.5.1.  I believe that is 64 bit mode, unless I'm just
> falling
> for the hype...

32 bit is the default, you have to either pass -m64 or -arch x86_64 to
the compiler to get 64 bit.

All Apple supplied executables (Xcode.app excepted) are fat ppc and
i386, and most libraries are 4-way fat (ppc, ppc64, i386, x86_64).

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: config.guess and $CC

[Peter O'Gorman]

Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
> 
>> On a bi-arch system (i.e. a system that can execute 32-bit mode binaries and
>> 64-bit mode binaries), what is the expected behaviour of config.guess?
>> Should it return different triplets for CC="gcc -m32" and CC="gcc -m64",
>> or the same?
> 
> My assumption all along has been that it should return different triplets.
> 
> It now strikes me, though: what about "fat binaries" and Mac OS X,
> where the same program is compiled for multiple architectures all at
> one go?  Should these get a special triplet, as compared to thin
> binaries?

I worry that changing this will break something. I would guess that a
number of configure scripts currently only check for ppc*darwin* and
i386*darwin* and make decisions based on that. You could have someone
doing something like

case $host in
i?86*-darwin*) mac=yes; macintel=yes ;;
*-darwin*) mac=yes; macintel=no ;;
esac

Returning anything but i?86-apple-darwin9.1.0 on an intel Mac OS X
10.5.1 for config.guess would break this. I doubt that people would
expect updating config.guess to break their configure scripts in this
manner.

Libtool HEAD will be affected by a change like this, for example.

Perhaps config.guess could take an argument to return a more specific
target alias? Hmm, seems yucky.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: getloadavg on aix5

[Peter O'Gorman]

On Mon, Jan 07, 2008 at 09:52:33PM -0600, Peter O'Gorman wrote:
> I seem to have lost Jim's reply, but here is a patch. Works on
> aix-4.3.3 and aix-5.3.

Hi,

ping?

http://lists.gnu.org/archive/html/bug-gnulib/2008-01/msg00068.html

Peter

Re: getloadavg on aix5

[Peter O'Gorman]

I seem to have lost Jim's reply, but here is a patch. Works on
aix-4.3.3 and aix-5.3.

The SBITS thing is the way the libperstat.h header recommends
calculating the loadavg:

/* To calculate the load average, divide the numbers by (1<. */

Of course, it is not defined on aix4.3.3 ...

Peter
diff --git a/lib/getloadavg.c b/lib/getloadavg.c
index eac8483..ec09919 100644
--- a/lib/getloadavg.c
+++ b/lib/getloadavg.c
@@ -30,6 +30,8 @@
If that isn't an option, then just put
AC_CHECK_FUNCS(pstat_getdynamic) in your
configure.in file.
+   HAVE_LIBPERFSTAT Define this if your system has the
+   perfstat_cpu_total function in libperfstat 
(AIX).
FIXUP_KERNEL_SYMBOL_ADDR()  Adjust address in returned struct nlist.
KERNEL_FILE Name of the kernel file to nlist.
LDAV_CVT()  Scale the load average from the kernel.
@@ -254,7 +256,7 @@
 #   define LOAD_AVE_TYPE long
 #  endif
 
-#  ifdef _AIX
+#  if defined (_AIX) && ! defined(HAVE_LIBPERFSTAT)
 #   define LOAD_AVE_TYPE long
 #  endif
 
@@ -309,7 +311,7 @@
 #   define FSCALE 100.0
 #  endif
 
-#  ifdef _AIX
+#  if defined (_AIX) && !defined(HAVE_LIBPERFSTAT)
 #   define FSCALE 65536.0
 #  endif
 
@@ -347,7 +349,7 @@
 #  define LDAV_SYMBOL "_Loadavg"
 # endif
 
-# if !defined (LDAV_SYMBOL) && ((defined (hpux) && !defined (hp9000s300)) || 
defined (_SEQUENT_) || defined (SVR4) || defined (ISC) || defined (sgi) || 
(defined (ardent) && defined (titan)) || defined (_AIX))
+# if !defined (LDAV_SYMBOL) && ((defined (hpux) && !defined (hp9000s300)) || 
defined (_SEQUENT_) || defined (SVR4) || defined (ISC) || defined (sgi) || 
(defined (ardent) && defined (titan)) || (defined (_AIX) && 
!defined(HAVE_LIBPERFSTAT)))
 #  define LDAV_SYMBOL "avenrun"
 # endif
 
@@ -404,6 +406,14 @@
 
 # endif /* LOAD_AVE_TYPE */
 
+# if defined (HAVE_LIBPERFSTAT)
+#  include 
+#  include 
+#  ifndef SBITS
+#   define SBITS 16
+#  endif
+# endif
+
 # if defined (__GNU__) && !defined (NeXT)
 /* Note that NeXT Openstep defines __GNU__ even though it should not.  */
 /* GNU system acts much like NeXT, for load average purposes,
@@ -485,6 +495,10 @@ static kvm_t *kd;
 #  endif /* SUNOS_5 */
 
 # endif /* LOAD_AVE_TYPE && !HAVE_LIBKSTAT */
+
+# if defined(HAVE_LIBPERFSTAT)
+static perfstat_cpu_total_t cpu_stats;
+# endif
 
 /* Put the 1 minute, 5 minute and 15 minute load averages
into the first NELEM elements of LOADAVG.
@@ -568,6 +582,18 @@ getloadavg (double loadavg[], int nelem)
 
 # endif /* hpux && HAVE_PSTAT_GETDYNAMIC */
 
+# if ! defined (LDAV_DONE) && defined(HAVE_LIBPERFSTAT)
+#  define LDAV_DONE
+#  undef LOAD_AVE_TYPE
+/* Use perfstat_cpu_total because we don't have to be root. */
+  int result = perfstat_cpu_total( NULL, &cpu_stats, sizeof(cpu_stats), 1);
+  if (result == -1) return result;
+  loadavg[0] = (double) cpu_stats.loadavg[0] / (double)(1 << SBITS);
+  loadavg[1] = (double) cpu_stats.loadavg[1] / (double)(1 << SBITS);
+  loadavg[2] = (double) cpu_stats.loadavg[2] / (double)(1 << SBITS);
+  elem = 3;
+# endif
+
 # if !defined (LDAV_DONE) && (defined (__linux__) || defined (__CYGWIN__))
 #  define LDAV_DONE
 #  undef LOAD_AVE_TYPE
diff --git a/m4/getloadavg.m4 b/m4/getloadavg.m4
index 8243729..c1547c7 100644
--- a/m4/getloadavg.m4
+++ b/m4/getloadavg.m4
@@ -31,6 +31,10 @@ AC_CHECK_FUNCS(pstat_getdynamic)
 AC_CHECK_LIB(kstat, kstat_open)
 test $ac_cv_lib_kstat_kstat_open = yes && gl_have_func=yes
 
+# AIX has libperfstat which does not require root
+AC_CHECK_LIB(perfstat, perfstat_cpu_total)
+test $ac_cv_lib_perfstat_perfstat_cpu_total = yes && gl_have_func=yes
+
 # Some systems with -lutil have (and need) -lkvm as well, some do not.
 # On Solaris, -lkvm requires nlist from -lelf, so check that first
 # to get the right answer into the cache.

getloadavg on aix5

[Peter O'Gorman]

Hi,

While getloadavg works ok on aix4, it returns incorrect results on
aix5.

Why do we not use libperfstat on aix?
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/basetrf1/perfstat_cputot.htm

It has the advantage of not requiring root privs to get the loadavg.

Anyway, this resulted in more accurate results for us.

Peter

--- lib/getloadavg.c~  2008-01-07 16:03:48.239700086 +
+++ lib/getloadavg.c   2008-01-07 16:26:43.014094746 +
@@ -255,7 +255,11 @@
 #  endif
 
 #  ifdef _AIX
-#   define LOAD_AVE_TYPE long
+#   ifdef _AIX51
+#define LOAD_AVE_TYPE long long
+#   else
+#define LOAD_AVE_TYPE long
+#   endif
 #  endif
 
 #  ifdef convex

Re: coreutils failure on Mac OS X 10.5

[Peter O'Gorman]

Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
> 
>>  * m4/putenv.m4 (gl_FUNC_PUTENV): Require gl_STDLIB_H_DEFAULTS. Instead
>>  of defining putenv in config.h, just set REPLACE_PUTENV.
> 
> Thanks for doing that.  I had written something quite similar but you
> beat me to it.  One minor change, which I just installed, is to tell
> users that we're testing for compatibility for GNU as well as for
> SVID.  (GNU is more important and better known these days than SVID.)

The test for putenv("FOO") removing FOO from the environment is, as far
as I am aware, only a GNU putenv feature (well, misfeature in my
opinion), so it is probably best to delete the SVID portion entirely.

http://www.opengroup.org/austin/mailarchives/ag/msg09682.html

Peter

Re: coreutils failure on Mac OS X 10.5

[Peter O'Gorman]

On Oct 29, 2007, at 10:09 PM, Bruno Haible wrote:


Peter O'Gorman wrote:

/usr/include/stdlib.h has
intputenv(char *) __DARWIN_ALIAS(putenv);

__DARWIN_ALIAS is defined as:
#define __DARWIN_ALIAS(sym)  __asm("_" __STRING(sym)
__DARWIN_SUF_UNIX03)

__DARWIN_SUF_UNIX03 is defined as "$UNIX2003" for 32 bit builds.

$ grep putenv lib/config.h
/* Define to rpl_putenv if the replacement function should be used.  
*/

#define putenv rpl_putenv


Fortunately, most function replacements in gnulib are now done by
including the original system header and then only doing the
 #define func rpl_func
Only those replacements that use the old idiom of putting
 #define func rpl_func
into config.h are affected.

What's the extent of the problem? The following functions are using  
the

__DARWIN_ALIAS or similar macros:

dirent.h closedir opendir __opendir2 rewinddir seekdir telldir
fnmatch.hfnmatch
ftw.hftw nftw
getopt.h getopt
pthread.hpthread_cancel pthread_cond_init  
pthread_cond_timedwait
pthread_cond_wait pthread_join  
pthread_mutexattr_destroy

pthread_rwlock_destroy pthread_rwlock_init
pthread_rwlock_rdlock pthread_rwlock_tryrdlock
pthread_rwlock_trywrlock pthread_rwlock_wrlock
pthread_rwlock_unlock pthread_setcancelstate
pthread_setcanceltype pthread_testcancel  
pthread_sigmask

regex.h  regcomp
signal.h kill killpg pthread_sigmask sigaltstack sigpause  
sigsuspend

sigwait
stdio.h  fputs freopen fwrite tempnam
stdlib.h strtod strtof system initstate putenv realpath  
setenv setkey

unsetenv
string.h strerror
sys/_select.hselect
sys/aio.haio_suspend
sys/fcntl.h  open creat fcntl
sys/mman.h   mmap mprotect msync munmap
sys/msg.hmsgctl msgrcv msgsnd
sys/poll.h   poll
sys/resource.h   getrlimit setrlimit
sys/select.h pselect
sys/sem.hsemctl
sys/semaphore.h  sem_wait
sys/shm.hshmctl
sys/socket.h accept bind connect getpeername getsockname listen  
recv

recvfrom recvmsg send sendmsg sendto socketpair
sys/stat.h   chmod fchmod
sys/termios.htcdrain
sys/uio.hreadv writev
sys/wait.h   wait waitpid waitid
time.h   clock mktime strftime strptime nanosleep
unistd.h close confstr encrypt fsync getopt lchown lockf  
nice pause
pread pwrite read setpgrp setregid setreuid sleep  
ttyname_r

usleep write setkey getattrlist setattrlist
wchar.h  wcsftime

Out of these, the following are defined with #define in :

 realpath
 mktime
 poll   # not a problem since gnulib's poll.h does not  
include 

 putenv
 regcomp# not a problem since gnulib's regex.h does not  
include 

 strtod

Can you please check these functions by doing

 ./gnulib-tool --test --with-tests canonicalize-lgpl mktime timegm  
putenv strtod


? Please show the "configure" output as well as all errors shown by  
"make -k".


We only saw problems in putenv, when it first came up I was quite  
worried that the issue was widespread, but could not tell this list  
due to non disclosure agreement. It seems that it is not as big a  
problem as I had first assumed.


All the tests pass. This is probably because the testsuite does not  
seem to use the functions at all (probably why you asked for the  
configure output).


Test output:
PASS: test-alloca-opt
PASS: test-canonicalize-lgpl.sh
PASS: test-malloca
PASS: test-stdlib
PASS: test-time
PASS: test-unistd
==
All 6 tests passed
==

Configure Output:

gllib/Makefile.am: installing `build-aux/depcomp'
executing aclocal -I ../glm4
executing autoconf
executing autoheader
executing automake --add-missing --copy
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ../build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking build system type... i386-apple-darwin9.0.0
checking host system type... i386-apple-darwin9.0.0
checking for ranlib... ran

Re: coreutils failure on Mac OS X 10.5

[Peter O'Gorman]

Jim Meyering wrote:
> Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> I am pretty sure that this is still the case with latest gnulib, but
>> have not checked.
>>
>> Coreutils fails to build on Mac OS X 10.5. Apple has worked hard to make
>> this version of Mac OS X UNIX(tm). To do so they had to change the
>> behavior of a number of functions. In order to maintain binary
>> compatibility with older releases they kept the old symbol names in libc
>> and named any functions that had to be modified to conform to the
>> standard symbol$UNIX2003. So libc has a putenv symbol and a
>> putenv$UNIX2003 symbol, the former behaves like BSD putenv, the latter
>> is unix03 conforming. When you #include , unless you #define
>> _NONSTD_SOURCE, the symbol putenv is renamed, using asm, to putenv$UNIX2003.
>>
>> What, you ask, does this have to do with gnulib? Well, when attempting
>> to compile GNU coreutils, we noticed that it was failing with undefined
>> symbols, specifically '_rpl_putenv$UNIX2003' (all C symbols on Mac OS X
> 
> Thanks for the report.
> Have you tried with a recent coreutils snapshot?
> 
> Can you provide more details?
> Like is this a link error?
> What is trying to use that symbol?

Yes, a link error, sorry for the crap bug report, too much background,
not enough detail:
With coreutils-6.9
gcc -std=gnu99  -g -O2   -o date date.o ../lib/libcoreutils.a
../lib/libcoreutils.a
Undefined symbols:
  "_rpl_putenv$UNIX2003", referenced from:
  _main in date.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [date] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
mb:coreutils-6.9 peter$ uname -a
Darwin mb.pogma.org 9.0.0 Darwin Kernel Version 9.0.0: Tue Oct  9
21:35:55 PDT 2007; root:xnu-1228~1/RELEASE_I386 i386

/usr/include/stdlib.h has
intputenv(char *) __DARWIN_ALIAS(putenv);

__DARWIN_ALIAS is defined as:
#define __DARWIN_ALIAS(sym)  __asm("_" __STRING(sym)
__DARWIN_SUF_UNIX03)

__DARWIN_SUF_UNIX03 is defined as "$UNIX2003" for 32 bit builds.

$ grep putenv lib/config.h
/* Define to rpl_putenv if the replacement function should be used. */
#define putenv rpl_putenv


Hope this helps.

Peter

coreutils failure on Mac OS X 10.5

[Peter O'Gorman]

Hi,

I am pretty sure that this is still the case with latest gnulib, but
have not checked.

Coreutils fails to build on Mac OS X 10.5. Apple has worked hard to make
this version of Mac OS X UNIX(tm). To do so they had to change the
behavior of a number of functions. In order to maintain binary
compatibility with older releases they kept the old symbol names in libc
and named any functions that had to be modified to conform to the
standard symbol$UNIX2003. So libc has a putenv symbol and a
putenv$UNIX2003 symbol, the former behaves like BSD putenv, the latter
is unix03 conforming. When you #include , unless you #define
_NONSTD_SOURCE, the symbol putenv is renamed, using asm, to putenv$UNIX2003.

What, you ask, does this have to do with gnulib? Well, when attempting
to compile GNU coreutils, we noticed that it was failing with undefined
symbols, specifically '_rpl_putenv$UNIX2003' (all C symbols on Mac OS X
are prefixed with an underscore). What is happening, of course, is that
the #define putenv rpl_putnev is combining with Apple's magic in the
headers to give us a symbol that does not exist.

Note that in this particular case, the gnulib check for putenv checks
that putenv("VAR") removes VAR from the environment. As far as I can
tell, this is a non-standard extension that is only available on
linux/glibc systems. Shouldn't people be using unsetenv for this?

Anyway, a quick hack fix, is to do ./configure ...
jm_cv_func_svid_putenv=yes ... for coreutils. So far the issue has only
been seen with coreutils and putenv, even though there are a fairly
large number of functions that get the renaming to $UNIX03 in the
headers, so it may be that the best short term solution is to change the
gnulib putenv check.

Any other suggestions?

Peter

Re: recent changes to gnulib stdio_.h break build on powerpc-ibm-aix4.3.3.0

[Peter O'Gorman]

On Mon, 2007-07-23 at 23:27 +0200, Bruno Haible wrote:
> Hello,
>   mkdir confdir1
>   mkdir confdir2
>   echo ... > confdir1/conftest.h
>   echo ... > confdir2/conftest.h
>   save_CPPFLAGS="$CPPFLAGS"
>   CPPFLAGS="$CPPFLAGS -Iconfdir1 -Iconfdir2"
>   AC_PREPROC_IFELSE([#include ], ...)
>   CPPFLAGS="$save_CPPFLAGS"
> 
> ? This should be more robust.

Hi,

Yes, that sounds good. Note that I have not done a copyright assignment
for gnulib, however this change is trivial.

Peter



--- m4/include_next.m4	2007-07-06 02:26:24.799263725 +
+++ m4/include_next.m4	2007-07-23 22:04:41.633470389 +
@@ -11,9 +11,23 @@
   AC_LANG_PREPROC_REQUIRE()
   AC_CACHE_CHECK([whether the preprocessor supports include_next],
 [gl_cv_have_include_next],
-[AC_PREPROC_IFELSE([#include_next ],
+[mkdir conftestd1 conftestd2
+cat << _gl_EOF > conftestd1/conftest.h
+#include_next 
+_gl_EOF
+cat << _gl_EOF > conftestd2/conftest.h
+int main () {
+  return 0;
+}
+_gl_EOF
+save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS -Iconftestd1 -Iconftestd2"
+AC_LINK_IFELSE([#include ],
[gl_cv_have_include_next=yes],
-   [gl_cv_have_include_next=no])])
+   [gl_cv_have_include_next=no])
+rm -rf conftestd1 conftestd2
+CPPFLAGS="$save_CPPFLAGS"
+])
   if test $gl_cv_have_include_next = yes; then
 
 dnl FIXME: Remove HAVE_INCLUDE_NEXT and update everything that uses it

Re: recent changes to gnulib stdio_.h break build on powerpc-ibm-aix4.3.3.0

[Peter O'Gorman]

On Sun, 2007-07-22 at 17:50 -0400, Gary V. Vaughan wrote:
> 
> The compile completes.  I suspect the problem affects all @INCLUDE_NEXT@
> using files on this host (stdio_.h is the only one that I've tripped  
> over
> so far).

include_next.m4 incorrectly deduces that this compiler understands
#include_next. The compiler issues a warning rather than an error when
it sees it.

This should fix:
 --- m4/include_next.m4~ 2007-07-18 03:21:47.089858027 +
+++ m4/include_next.m4  2007-07-23 14:21:26.312399370 +
@@ -11,9 +11,11 @@
   AC_LANG_PREPROC_REQUIRE()
   AC_CACHE_CHECK([whether the preprocessor supports include_next],
 [gl_cv_have_include_next],
-[AC_PREPROC_IFELSE([#include_next ],
+[save_werror_flag=$ac_c_werror_flag; ac_c_werror_flag=yes
+   AC_PREPROC_IFELSE([#include_next ],
[gl_cv_have_include_next=yes],
-   [gl_cv_have_include_next=no])])
+   [gl_cv_have_include_next=no])
+   ac_c_werror_flag=$save_werror_flag])
   if test $gl_cv_have_include_next = yes; then
 
 dnl FIXME: Remove HAVE_INCLUDE_NEXT and update everything that uses
it

Peter

Re: Building universal binaries makes 'check' fail

[Peter O'Gorman]

On Mar 1, 2007, at 9:20 AM, Paul Eggert wrote:


Elias Pipping <[EMAIL PROTECTED]> writes:


autoconf fails for me with

177: AC_C_BIGENDIAN  FAILED (semantics.at:478)


Thanks for testing this.  I have installed the following additional
patch, which I hope fixes your problem.  It also fixes the misspelling
noted by Paolo Bonzini.  Please give it a try when you have the time.


Hi Paul,

What if the package does not use AC_CONFIG_HEADERS? This patch will  
fail. What about AC_CHECK_SIZEOF which will report incorrect results  
if -arch i386 -arch x86_64 are specified for example? Thanks for  
checking in this patch which will make things easier to build fat  
most of the time, but it is not without problems.


Peter

Re: Building universal binaries makes 'check' fail

[Peter O'Gorman]

On Mar 1, 2007, at 8:34 AM, Elias Pipping wrote:


On Mar 1, 2007, at 12:18 AM, Peter O'Gorman wrote:

Apple suggests using their lipo tool to create universal binaries  
from multiple single architecture runs of configure and make.


Where do they do that? I was following

http://developer.apple.com/technotes/tn2005/tn2137.html


While I do have bugs open on that technote - from that page:
Merging multiple builds

While the GNU Hello program is one of the most complicated "Hello,  
World" programs ever written, it is still a relatively simple  
program: it does not care about byte order, word size, or pointer  
size; nor does the configuration process generate any executables  
which themselves produce configuration files based on the machine  
target. Not all Open Source projects are this simple. For them, there  
is another approach, which involves using the lipo command.




Peter

Re: Building universal binaries makes 'check' fail

[Peter O'Gorman]

On Feb 28, 2007, at 12:47 PM, Elias Pipping wrote:


Hello,

autoconf fails for me with

177: AC_C_BIGENDIAN  FAILED (semantics.at:478)


I am not sure it is worth the effort to get autoconf "clean" for  
Apple's universal builds. The whole autoconf philosophy is about  
checking header/library availability and system features. These will  
differ on different systems building the same code with the same  
options if there are differences in cputype etc. Apple suggests using  
their lipo tool to create universal binaries from multiple single  
architecture runs of configure and make.


It should be decided whether the effort is worth it before continuing  
to patch for this.


Peter

Re: use of -fno-common on Darwin

[Peter O'Gorman]

Bruno Haible wrote:

Paul Eggert wrote:


"Peter O'Gorman" <[EMAIL PROTECTED]> writes:


getprogname(3), if it exists, can be used as well as other
alternatives (e.g. argv[0]).


Thanks, I wasn't aware of the BSD getprogname until now.



Me too.



How about this proposal?

* Change the progname module to use the BSD getprogname naming
 convention.  No sense reinventing the wheel.  That way, programs can
 simply use the system-defined functions on BSD.

* Rewrite the other gnulib code to use the new convention.

* Ask gnulib users to switch to the new convention.



Yes, that's the most sensible thing to do. If there are no objections,
I will change the 'progname' module accordingly.

[libtool list cut]

Solaris seems to have a getexecname, so between, getprogname, getexecname 
and program_invocation_short_name, BSD, solaris and glibc using OSes are 
covered. I'd suggest the following instead of Paul's proposal, as it allows 
the programmer to override the program name. Given that though, Paul's 
proposal is better than current.


static char * prog_name = NULL;

void
set_prog_name(char * name)
{
if (prog_name) free(prog_name);
prog_name = strdup(name);
}

char *
get_prog_name(void)
{
char * name;
if (prog_name)
name = prog_name;
else
{
#if defined(HAVE_GETPROGNAME)
#include 
name = getprogname();
#elif defined(HAVE_GETEXECNAME)
#include 
name = getexecname();
#elif defined(HAVE_PROGRAM_INVOCATION_SHORT_NAME)
#include 
name = program_invocation_short_name;
#else
name = "executable";
#endif
}
return name;
}


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of -fno-common on Darwin

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues wrote:
| [ This is http://article.gmane.org/gmane.comp.lib.gnulib.bugs/5080
|   Please remove bug-gnulib from followups.  Thank you. ]
|
| * Paul Eggert wrote on Fri, Jan 06, 2006 at 12:06:59AM CET:
|
|>[EMAIL PROTECTED] (Karl Berry) writes:
|>
|>
|>>Is it a problem in practice, ie, what are these non-Unix linkers?
|>
|>I've run into it on IBM mainframe platforms.  You can run into it even
|>with GCC, if you use -fno-common.  Googling a bit reveals that libtool
|>1.5 uses -fno-common on Mac OS X (why, I don't know; see
|>).
|
|
| A couple of observations on this topic: It was introduced here
| http://lists.gnu.org/archive/html/libtool-patches/2001-03/msg00053.html
| as "necessary to build shared libraries", and this documentation
|
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/executing_files.html
| mentions this for multi-module shared libraries.
|
| Now we've had this discussion recently
| http://lists.gnu.org/archive/html/libtool-patches/2005-12/msg4.html
| to use -single_module by default, which would enable us to kill
| -fno-common, except we don't know at compile time whether the user will
| specify -multi_module at link time.  In any case changing pic_flag may
| break ABI of some libraries (but also enable to build some others, esp.
| Fortran ones).
|
| Comments?

I will not support the removal of -fno-common on darwin. Older darwin
systems developer tools do not support -single_module. The gnulib use of
program_name is annoying, getprogname(3), if it exists, can be used as well
as other alternatives (e.g. argv[0]).

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ8KpWLiDAg3OZTLPAQJr6wP+O4/uKPVYiq9dNhJ6/2nGppi0aWXgXdq9
/E10Izp9ibmH3SslrOPZWhLwpldLbU1vDK36knb+qrK849+3+lh38GnpWeMei20h
z8UktKpaHXnpPMj81GzZWhInx1RxgCwsBpmLI8OEH81GK5vwwrPZjlhhTjaRvTg8
F0m6+7EaguU=
=08P1
-END PGP SIGNATURE-


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: mmapping of /dev/zero always fails on darwin

[Peter O'Gorman]

Peter O'Gorman wrote:

Looks like the cvs folks need to update their gnulib.


Of course, they have done this, and I feel silly.

Peter


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: mmapping of /dev/zero always fails on darwin

[Peter O'Gorman]

Bruno Haible wrote:

Are you sure that this is what gnulib does? Darwin's  defines
MAP_ANON, then gnulib's m4/mmap-anon.m4 macro ought to add
  #define MAP_ANONYMOUS MAP_ANON
  #define HAVE_MAP_ANONYMOUS 1
to config.h, and then lib/pagealign_alloc.c should be doing

  mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0);

Is pagealign_alloc.c doing this or not?


Ah ha!

Looks like the cvs folks need to update their gnulib.



Sorry for the noise,
Peter



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: mmapping of /dev/zero always fails on darwin

[Peter O'Gorman]

Derek Price wrote:



I don't suppose you could come up with a configure test or a short C
program that fails to compile (preferrably) or run (if necessary) to
spot this, short of actually switching on the system name or something
similar?


The test would have to be a run test, which would mean having a 
cross-compile alternative switching on the system name (this is why gcc 
switches on name).


Just doing the same thing as gnulib does will show the failure:

int main(){
void * address = NULL;
static int fd =-1;
int ret = 0;
fd = open ("/dev/zero",O_RDONLY,666);
ret = mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_FILE | 
MAP_PRIVATE, fd, 0);

if (ret != MAP_FAILED) return 0;
return 1;
}

Hope this helps,
Peter


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

mmapping of /dev/zero always fails on darwin

[Peter O'Gorman]

Hi,
I just tried to use cvs-1.12.12 on Mac OS X, and it always dies. I traced 
the problem to pagealign_alloc.c, which attempts to mmap /dev/zero.



As you can see from this little snippet of gcc configure, you can't mmap 
/dev/zero on darwin.


   AC_CACHE_CHECK([whether mmap from /dev/zero works],
  gcc_cv_func_mmap_dev_zero,
  [# Add a system to this blacklist if it has mmap() but /dev/zero
   # does not exist, or if mmapping /dev/zero does not give anonymous
   # zeroed pages with both the following properties:
   # 1. If you map N consecutive pages in with one call, and then
   #unmap any subset of those pages, the pages that were not
   #explicitly unmapped remain accessible.
   # 2. If you map two adjacent blocks of memory and then unmap them
   #both at once, they must both go away.
   # Systems known to be in this category are Windows (all variants),
   # VMS, and Darwin.
   case "$host_os" in
 vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
gcc_cv_func_mmap_dev_zero=no ;;
 *)
gcc_cv_func_mmap_dev_zero=yes;;
   esac])

Thanks,
Peter


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib