Re: mmapping of /dev/zero always fails on darwin
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
Re: [bug-gnulib] Re: mmapping of /dev/zero always fails on darwin
Bruno Haible wrote: Are you sure that this is what gnulib does? Darwin's sys/mman.h 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. http://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/m4/mmap-anon.m4.diff?r1=1.4r2=1.5 Sorry for the noise, 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 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: use of -fno-common on Darwin
-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 |http://www.tug.org/pipermail/tex-k/2003-June/000723.html). | | | 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: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
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: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
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: support for universal binaries on MacOS X (5/6)
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: Building universal binaries makes 'check' fail
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
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: recent changes to gnulib stdio_.h break build on powerpc-ibm-aix4.3.3.0
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 stddef.h], +[save_werror_flag=$ac_c_werror_flag; ac_c_werror_flag=yes + AC_PREPROC_IFELSE([#include_next stddef.h], [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: recent changes to gnulib stdio_.h break build on powerpc-ibm-aix4.3.3.0
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 conftest.h], ...)
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 stddef.h],
+[mkdir conftestd1 conftestd2
+cat _gl_EOF conftestd1/conftest.h
+#include_next conftest.h
+_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 conftest.h],
[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
coreutils failure on Mac OS X 10.5
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 stdlib.h, 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: coreutils failure on Mac OS X 10.5
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
getloadavg on aix5
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: getloadavg on aix5
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 (1SBITS). SBITS is defined in sys/proc.h. */ 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 libperfstat.h +# include sys/proc.h +# 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.
Re: getloadavg on aix5
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: config.guess and $CC
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: frexpl bugs remain on OS X 10.5 intel
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
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: config.guess and $CC
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
time_r.m4 checks unexpectedly pass on hpux10
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 time.h
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: environ on MacOS X
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 crt_externs.h + #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
Re: environ on MacOS X
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 crt_externs.h
#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 21
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: time_r.m4 checks unexpectedly pass on hpux10
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
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
AIX 5.1 xlc va_copy (stdarg patch)
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 stdarg.h 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 stdarg.h.
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 stdarg.h], [
@@ -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 stdarg.h 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 stdarg.h 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 stdarg.h
--- /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: AIX 5.1 xlc va_copy (stdarg patch)
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 stdarg.h.
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 stdarg.h], [
@@ -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 stdarg.h 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 stdarg.h 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 stdarg.h
--- /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 */
Re: AIX 5.1 xlc va_copy (stdarg patch)
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)
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)
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 stdarg.h
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 stdarg.h.
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 stdarg.h], [
@@ -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 stdarg.h 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 stdarg.h 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 stdarg.h
--- /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)
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 stdarg.h 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 stddef.h or stdarg.h on this system does a #undef va_copy. (You said stddef.h, but your patch looks like you meant stdarg.h?) 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)
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 stdarg.h.
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 stdarg.h], [
@@ -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 stdarg.h 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 stdarg.h 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 stdarg.h
--- /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) *ping*
ping? http://lists.gnu.org/archive/html/bug-gnulib/2008-02/msg00148.html Peter
Re: AIX 5.1 xlc va_copy (stdarg patch)
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: inline related build failures on MacOS X 10.5
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: Can't build libposix
On 12/11/2010 11:09 PM, Bastien ROUCARIES wrote: On Sun, Dec 12, 2010 at 10:04 AM, Peter O'Gormanpe...@pogma.com 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: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX
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 egg...@cs.ucla.edu 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
Tru64 dtk vsnprintf module build failure
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 stdio.h before the #include wchar.h in printf-args.h, but I'm not sure that it's correct. Gnulib undoubtedly has many more #include wchar.h that may be missing a prior #include stdio.h 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 stddef.h +/* Tru64 with Desktop Toolkit C has a bug: stdio.h must be included before + wchar.h. */ + +#ifndef __GLIBC__ +# include stdio.h +#endif + /* Get wchar_t. */ #if HAVE_WCHAR_T # include stddef.h
Re: Tru64 dtk vsnprintf module build failure
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 wchar.h. Thanks! Peter -- Peter O'Gorman po...@thewrittenword.com
Re: MacOS X 10.7 and gettext
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
pwrite module
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 po...@thewrittenword.com
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 po...@thor.il.thewrittenword.com
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 po...@thewrittenword.com
+
+ 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 ebl...@redhat.com
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
Re: pwrite module
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
Re: init.sh: enable MALLOC_PERTURB_
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
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 po...@thor.il.thewrittenword.com
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 po...@thewrittenword.com
+
+ Remove useless test-pwrite.sh file.
+ * test/test-pwrite.sh: Delete file.
+ * module/pwrite-tests: Remove references.
+
2010-05-10 Jim Meyering meyer...@redhat.com
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 po...@thor.il.thewrittenword.com
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 po...@thewrittenword.com
+ 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: pwrite module
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
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: test-vc-list-files-cvs.sh failure on OS X 10.6.3
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: [libvirt] [PATCH] util: fix thinko in runIO
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
