config.rpath conflict
Hi! Some modules, e.g. havelib, ship a config.rpath into build-aux. However, autopoint doesn't like this file and complains: [EMAIL PROTECTED]:~/src/gnutls$ autopoint autopoint: File build-aux/config.rpath has been locally modified. autopoint: *** Some files have been locally modified. Not overwriting them because --force has not been specified. For your convenience, you find the local modifications in the file '/tmp/gtl31708/autopoint.diff'. autopoint: *** Stop. [EMAIL PROTECTED]:~/src/gnutls$ autopoint --verison In the past, I have just removed the gnulib config.rpath copy, but this seems like the wrong thing. Any suggestions? Would this problem go away if gnulib's copy is updated? The diff mentioned above is included below. Further, the diff hints that the needs of gettext and libtool from config.rpath are slightly different. Is that correct? Does it matter which script is used by each tool? /Simon *** config.rpath2006-07-21 15:36:21.0 +0200 --- build-aux/config.rpath 2007-03-05 12:28:06.0 +0100 *** *** 488,520 --- 488,541 # Check dynamic linker characteristics # Code taken from libtool.m4's AC_LIBTOOL_SYS_DYNAMIC_LINKER. + # Unlike libtool.m4, here we don't care about _all_ names of the library, but + # only about the one the linker finds when passed -lNAME. This is the last + # element of library_names_spec in libtool.m4, or possibly two of them if the + # linker has special search rules. + library_names_spec= # the last element of library_names_spec in libtool.m4 libname_spec='lib$name' case "$host_os" in aix3*) + library_names_spec='$libname.a' ;; aix4* | aix5*) + library_names_spec='$libname$shrext' ;; amigaos*) + library_names_spec='$libname.a' ;; beos*) + library_names_spec='$libname$shrext' ;; bsdi[45]*) + library_names_spec='$libname$shrext' ;; cygwin* | mingw* | pw32*) shrext=.dll + library_names_spec='$libname.dll.a $libname.lib' ;; darwin* | rhapsody*) shrext=.dylib + library_names_spec='$libname$shrext' ;; dgux*) + library_names_spec='$libname$shrext' ;; freebsd1*) ;; kfreebsd*-gnu) + library_names_spec='$libname$shrext' ;; freebsd* | dragonfly*) + case "$host_os" in + freebsd[123]*) + library_names_spec='$libname$shrext$versuffix' ;; + *) + library_names_spec='$libname$shrext' ;; + esac ;; gnu*) + library_names_spec='$libname$shrext' ;; hpux9* | hpux10* | hpux11*) case $host_cpu in *** *** 528,537 --- 549,561 shrext=.sl ;; esac + library_names_spec='$libname$shrext' ;; interix3*) + library_names_spec='$libname$shrext' ;; irix5* | irix6* | nonstopux*) + library_names_spec='$libname$shrext' case "$host_os" in irix5* | nonstopux*) libsuff= shlibsuff= *** *** 549,588 --- 573,628 linux*oldld* | linux*aout* | linux*coff*) ;; linux*) + library_names_spec='$libname$shrext' ;; knetbsd*-gnu) + library_names_spec='$libname$shrext' ;; netbsd*) + library_names_spec='$libname$shrext' ;; newsos6) + library_names_spec='$libname$shrext' ;; nto-qnx*) + library_names_spec='$libname$shrext' ;; openbsd*) + library_names_spec='$libname$shrext$versuffix' ;; os2*) libname_spec='$name' shrext=.dll + library_names_spec='$libname.a' ;; osf3* | osf4* | osf5*) + library_names_spec='$libname$shrext' ;; solaris*) + library_names_spec='$libname$shrext' ;; sunos4*) + library_names_spec='$libname$shrext$versuffix' ;; sysv4 | sysv4.3*) + library_names_spec='$libname$shrext' ;; sysv4*MP*) + library_names_spec='$libname$shrext' ;; sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*) + library_names_spec='$libname$shrext' ;; uts4*) + library_names_spec='$libname$shrext' ;; esac sed_quote_subst='s/\(["`$\\]\)/\\\1/g' escaped_wl=`echo "X$wl" | sed -e 's/^X//' -e "$sed_quote_subst"` shlibext=`echo "$shrext" | sed -e 's,^\.,,'` + escaped_libname_spec=`echo "X$libname_spec" | sed -e 's/^X//' -e "$sed_quote_subst"` + escaped_library_names_spec=`echo "X$library_names_spec" | sed -e 's/^X//' -e "$sed_quote_subst"` escaped_hardcode_libdir_flag_spec=`echo "X$hardcode_libdir_flag_spec" | sed -e 's/^X//' -e "$sed_quote_subst"` LC_ALL=C sed -e 's/^\([a-zA-Z0-9_]*\)=/acl_cv_\1=/' <
Re: GNU M4 1.4.8b released (beta release)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 3/2/2007 9:33 AM: > >> Another option would be to leave int64_t defined as it is, but set >> HAVE_INT64_T >> to 0, to indicate that gnulib shouldn't use it. > > Hmm... this looks like it would fix sys/stat.h (see below). I'm still > not sure I trust it. Will clock_t and fpos_t be defined correctly so as > to not break system API's using these? Will gnulib behave correctly > w.r.t. these? We don't have access to your system, so you will have to try various experiments. One thing that would be helpful is for you to determine how packages will behave as though the .m4 files were fixed to already recognize that gnulib's assumptions about long long are broken, and therefore, from gnulib's point of view, a working long long does not exist (leaving actual system headers to use long long to their hearts content, unmolested by gnulib's replacement stdint.h). Can you try 'ac_cv_type_long_long_int=no ac_cv_type_unsigned_long_long_int=no ac_cv_type_long_long=no ./configure' and see if that can build a working image? > >> - what is the original definition of int64_t on this OS if gnulib is >> not >> involved? (a macro, a typedef?) > > sys/types.h has: > > #ifdef __TANDEM > #define int64_t long long > #else > typedef double int64_t; > #endif > > (__TANDEM is normally defined; the alternative is clearly a hack of sorts.) So this part of stdint_.h could use an edit to not unconditionally undefine int64_t: #undef int64_t #if LONG_MAX >> 31 >> 31 == 1 # define int64_t long int #elif defined _MSC_VER # define int64_t __int64 #elif @HAVE_LONG_LONG_INT@ # define int64_t long long int #endif instead, it should look like #if LONG_MAX >> 31 >> 31 == 1 # undef int64_t # define int64_t long int #elif defined _MSC_VER # undef int64_t # define int64_t __int64 #elif @HAVE_LONG_LONG_INT@ # undef int64_t # define int64_t long long int #endif Can you test (preferably independently of the earlier test) whether that edit helps matters any? There may be further edits necessary, since later parts of stdint_.h currently depend on whether int64_t is defined, when they should really depend on whether int64_t is defined by gnulib (since you've already proven that it is defined by your platform, but that gnulib doesn't really work with 64-bit types on your platform). > > Oh, and clock_t, dev_t and fpos_t are also 'long long', and 'long long' > shows up in several places in socket code (not sure if that's an issue > or not, since so far we aren't talking about any networking apps). > Shouldn't matter - gnulib can't redefine 'long long' since it occupies multiple tokens; and as long as gnulib doesn't use long long, we shouldn't be running afoul of your compiler's (awful) limitations. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7CYN84KuGfSFAYARAjO+AJ46Doiy2s1XsbSW/jfsXMlpsFGyFwCfX/DD Z5yVe/O6LQzoVu/kfpM5u7w= =oAU2 -END PGP SIGNATURE-
Re: check for C99-compliant snprintf - call for volunteers
Hello Bruno, * Bruno Haible wrote on Sun, Mar 04, 2007 at 03:57:00PM CET: [...] Volunteers wanted: If you have access to a system with [...] could you please run the configure script from the attached package and report the results? | 1 2 3 4 5 6 7 | OpenBSD 3.9 . # . . . . . | HP-UX 10.20 # # . . . . # | NetBSD 4.99.13 . . . . . . . Not sure why my HP-UX results differ from yours, I did not investigate at all. Cheers, Ralf
Re: first draft of "relocatable" module
* Ben Pfaff wrote on Sun, Mar 04, 2007 at 09:29:53PM CET: Bruno Haible <[EMAIL PROTECTED]> writes: > If we recommend to use > > ./configure --enable-relocatable --prefix=/etc > make > make install DESTDIR=/tmp/inst$$ > > then there should not be a security problem any more, right? I tend to just use --prefix=$HOME/inst$$. FWIW, I like that better, too. Or use some other path that only root can write to, like /opt or /nonexistent. > > That's a trivial attack on the systems where run path overrides the > > shared library path variable. > Thanks for explaining. It's not trivial - you have to know a bit about > LD_LIBRARY_PATH, -rpath, LD_RUN_PATH and the like, in order to understand it. Yeah, I meant, once you've understood it, it's trivial to implement. Sorry, upon rereading I have certainly communicated this poorly. Cheers, Ralf
Re: first draft of "relocatable" module
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ben Pfaff wrote on Sun, Mar 04, 2007 at 09:29:53PM CET:
>> Bruno Haible <[EMAIL PROTECTED]> writes:
>>
>> > If we recommend to use
>> >
>> > ./configure --enable-relocatable --prefix=/etc
>> > make
>> > make install DESTDIR=/tmp/inst$$
>> >
>> > then there should not be a security problem any more, right?
>>
>> I tend to just use --prefix=$HOME/inst$$.
>
> FWIW, I like that better, too. Or use some other path that only root
> can write to, like /opt or /nonexistent.
Here's some suggested wording then:
--- relocatable.texi.~1.3.~ 2007-03-03 12:23:49.0 -0800
+++ relocatable.texi2007-03-05 11:37:31.0 -0800
@@ -24,12 +24,16 @@ To configure a program to be relocatable
@option{--enable-relocatable} to the @program{configure} command line.
For reliability, it is best to also give a @option{--prefix} option
pointing to an otherwise unused (and never used again) directory,
-e.g.@: @option{--prefix=/tmp/inst$$}. This is recommended because on
+e.g.@: @option{--prefix=$HOME/inst$$} or
[EMAIL PROTECTED]/nonexistent}. This is recommended because on
some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
-directory.
+directory. Locations writable by unprivileged users, such as
[EMAIL PROTECTED]/tmp/inst$$}, are not recommended because such users can
+re-create a directory with the same name after the original directory
+has been removed.
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
pour encourager les autres."
--Voltaire, _Candide_
Re: first draft of "relocatable" module
On Mon, Mar 05, 2007 at 08:28:31PM +0100, Ralf Wildenhues wrote: > >I tend to just use --prefix=$HOME/inst$$. > > FWIW, I like that better, too. Or use some other path that only root > can write to, like /opt or /nonexistent. I strongly recommend you use /nonexistent instead of $HOME. If $HOME is behind an NFS automounter, and your program searches for anything in its $prefix, then this can slow things to a crawl. -- Daniel Jacobowitz CodeSourcery
Re: first draft of "relocatable" module
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I tend to just use --prefix=$HOME/inst$$.
and then later:
> Here's some suggested wording then:
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> I strongly recommend you use /nonexistent instead of $HOME. If $HOME
> is behind an NFS automounter, and your program searches for anything
> in its $prefix, then this can slow things to a crawl.
Good point. Here's some better wording taking that into account:
*** relocatable.texi.~1.3.~ 2007-03-03 12:23:49.0 -0800
--- relocatable.texi2007-03-05 11:54:53.0 -0800
***
*** 22,35
To configure a program to be relocatable, add
@option{--enable-relocatable} to the @program{configure} command line.
! For reliability, it is best to also give a @option{--prefix} option
! pointing to an otherwise unused (and never used again) directory,
! e.g.@: @option{--prefix=/tmp/inst$$}. This is recommended because on
! some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
! directory.
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--- 22,54
To configure a program to be relocatable, add
@option{--enable-relocatable} to the @program{configure} command line.
!
! On some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
! directory. Thus, for reliability, it is best to also give a
! @option{--prefix} option pointing to a directory that does not exist
! now and which never will be created, e.g.@:
! @option{--prefix=/nonexistent}. You may use
! @[EMAIL PROTECTED] on the @program{make} command line to
! avoid installing into that directory.
!
! We do not recommend using a prefix writable by unprivileged users
! (e.g.@: @file{/tmp/inst$$}) because such a directory can be recreated
! by an unprivileged user after the original directory has been removed.
! We also do not recommend prefixes that might be behind an automounter
! (e.g.@: @file{$HOME/inst$$}) because of the performance impact of
! directory searching.
!
! Here's a sample installation run that takes into account all these
! recommendations:
!
! @example
! ./configure --enable-relocatable --prefix=/nonexistent
! make
! make install DESTDIR=/tmp/inst$$
! @end example
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--
Positronic Functional Android Fabricated for Fighting
Re: printf-frexp and the radix of floating point numbers
Bruno Haible <[EMAIL PROTECTED]> writes: > If FLT_RADIX = 16, multiplication of a number with 2.0 causes rounding > errors for 25% of the numbers, and multiplication with 0.5 causes rounding > errors for 75% of the numbers. (Btw, this makes it impossible to implement > a C99 compatible frexp() function, no?) C99 doesn't require the answer to be exact, so it should be possible to implement frexp even when FLT_RADIX = 16.
Re: check for C99-compliant snprintf
Ralf Wildenhues wrote:
> | 1 2 3 4 5 6 7
> | OpenBSD 3.9 . # . . . . .
> | HP-UX 10.20 # # . . . . #
> | NetBSD 4.99.13 . . . . . . .
Thanks for these results. I've added them to printf.m4. For NetBSD, the
printf improvements (which they borrowed from FreeBSD) appear to be also
on the branch for NetBSD 4.0, therefore I've noted "NetBSD 4" instead of
NetBSD 4.99.13, although I couldn't directly test it.
> Not sure why my HP-UX results differ from yours, I did not investigate
> at all.
The failures of %n on HP-UX were in the truncated tail of an snprintf() call.
I've now added the corresponding test:
2007-03-05 Bruno Haible <[EMAIL PROTECTED]>
* m4/printf.m4 (gl_SNPRINTF_DIRECTIVE_N): New macro.
*** m4/printf.m45 Mar 2007 23:51:20 - 1.8
--- m4/printf.m46 Mar 2007 00:44:21 -
***
*** 1,4
! # printf.m4 serial 1
dnl Copyright (C) 2003, 2007 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4
! # printf.m4 serial 2
dnl Copyright (C) 2003, 2007 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***
*** 368,373
--- 368,432
])
])
+ dnl Test whether the snprintf function supports the %n format directive
+ dnl also in truncated portions of the format string. (ISO C99, POSIX:2001)
+ dnl Result is gl_cv_func_snprintf_directive_n.
+
+ AC_DEFUN([gl_SNPRINTF_DIRECTIVE_N],
+ [
+ AC_REQUIRE([AC_PROG_CC])
+ AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+ AC_CACHE_CHECK([whether snprintf fully supports the 'n' directive],
+ [gl_cv_func_snprintf_directive_n],
+ [
+ AC_TRY_RUN([
+ #include
+ #include
+ static char buf[100];
+ int main ()
+ {
+ int count = -1;
+ snprintf (buf, 4, "%d %n", 12345, &count, 33, 44, 55);
+ if (count != 6)
+ return 1;
+ return 0;
+ }], [gl_cv_func_snprintf_directive_n=yes],
[gl_cv_func_snprintf_directive_n=no],
+ [
+ changequote(,)dnl
+case "$host_os" in
+dnl Guess yes on glibc systems.
+ *-gnu*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on FreeBSD >= 5.
+ freebsd[1-4]*)gl_cv_func_snprintf_directive_n="guessing no";;
+ freebsd* | kfreebsd*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on MacOS X >= 10.3.
+ darwin[1-6].*)gl_cv_func_snprintf_directive_n="guessing no";;
+ darwin*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on Solaris >= 2.6.
+ solaris2.[0-5]*) gl_cv_func_snprintf_directive_n="guessing no";;
+ solaris*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on AIX >= 4.
+ aix[1-3]*)gl_cv_func_snprintf_directive_n="guessing no";;
+ aix*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on IRIX >= 6.5.
+ irix6.5) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on OSF/1 >= 5.
+ osf[3-4]*)gl_cv_func_snprintf_directive_n="guessing no";;
+ osf*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on NetBSD >= 3.
+ netbsd[1-2]* | netbsdelf[1-2]* | netbsdaout[1-2]* | netbsdcoff[1-2]*)
+gl_cv_func_snprintf_directive_n="guessing no";;
+ netbsd*) gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl Guess yes on BeOS.
+ beos*)gl_cv_func_snprintf_directive_n="guessing
yes";;
+dnl If we don't know, assume the worst.
+ *)gl_cv_func_snprintf_directive_n="guessing no";;
+esac
+ changequote([,])dnl
+ ])
+ ])
+ ])
+
dnl The results of these tests on various platforms are:
dnl
dnl 1 = gl_PRINTF_SIZES_C99
***
*** 377,382
--- 436,442
dnl 5 = gl_SNPRINTF_PRESENCE
dnl 6 = gl_SNPRINTF_TRUNCATION_C99
dnl 7 = gl_SNPRINTF_RETVAL_C99
+ dnl 8 = gl_SNPRINTF_DIRECTIVE_N
dnl
dnl 1 = checking whether printf supports size specifiers as in C99...
dnl 2 = checking whether printf supports the 'a' and 'A' directives...
***
*** 385,411
dnl 5 = checking for snprintf...
dnl 6 = checking whether snprintf truncates the result as in C99...
dnl 7 = checking whether s
Re: check for C99-compliant snprintf - call for volunteers
Daniel Jacobowitz wrote: > What GDB wants to print in hex floating isn't a host double but a > target double; if we cast to host double or long double, then in some > circumstances we lose precision. For this, in general, you could probably use gnulib's vasnprintf.c source with a lot of #ifdefs. And especially the code that does the actual conversion for 'a' and 'A' is unusable if 'double' is not the same as the target 'double'. Using snprintfv seems better for you - there you can redefine each directive's execution independently. > Anyway, I'm stalled for a while on snprintfv Why? Paolo presented a nice plan [1]. It only needs to be executed. Bruno [1] http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00426.html
Re: config.rpath conflict
Hi Simon, > Some modules, e.g. havelib, ship a config.rpath into build-aux. > However, autopoint doesn't like this file and complains: > > [EMAIL PROTECTED]:~/src/gnutls$ autopoint > autopoint: File build-aux/config.rpath has been locally modified. > autopoint: *** Some files have been locally modified. Not overwriting them > because --force has not been specified. For your convenience, you find the > local modifications in the file '/tmp/gtl31708/autopoint.diff'. > autopoint: *** Stop. > > In the past, I have just removed the gnulib config.rpath copy, but > this seems like the wrong thing. > > Any suggestions? The config.rpath in gnulib is newer than the one from the latest gettext release (0.16.1). Therefore I would move build-aux/config.rpath away so that autopoint doesn't see it, and then move it back. > Does it matter which script is used by each tool? It matters for OpenBSD users. > Would this problem go away if gnulib's copy is updated? This problem will only go away when either the integration between gettextize and automake is improved (but this is stalled since apparently currently noone with automake skills seriously wants to work with me on it), or when gnulib-tool is mature enough that it can replace gettextize and autopoint. Until then, you have to overwrite autopoint'ed files with copies brought in by gnulib-tool. Bruno
Re: check for C99-compliant snprintf - call for volunteers
On Tue, Mar 06, 2007 at 02:09:01AM +0100, Bruno Haible wrote: > Using snprintfv seems better for you - there you can redefine each directive's > execution independently. Yes - that's exactly my plan :-) > > Anyway, I'm stalled for a while on snprintfv > > Why? Paolo presented a nice plan [1]. It only needs to be executed. Sorry, "stalled" may not have been the right word. I am totally in support of Paolo's plan, and I began executing it, but a big project has come up at work - so I'm out of time, for the next couple of weeks. I hope that if no one else does sooner, I'll be back to it. -- Daniel Jacobowitz CodeSourcery
st_birthtime
I see that FreeBSD and NetBSD support st_birthtime. I'm considering supporting these in findutils. Is there any interest in suporting (i.e. maintaining if I contribute a patch) this in stat-time.h? If there is interest in maintaining the feature, how should we handle systems (like Linux) where this is not supported? By having the caller of stat-stime.h inline functions check HAVE_STRUCT_STAT_ST_BIRTHTIME itself? James.
Re: Building universal binaries makes 'check' fail
"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > 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? Those problems existed in the previous Autoconf version too, so the patch shouldn't made things worse. Since the patch does fix the problem for coreutils on a real platform it seems like it's a win. We can solve the other problems later, as needed.
Re: reorganize relocwrapper dependencies
> 2007-03-03 Bruno Haible <[EMAIL PROTECTED]> > > * modules/relocatable-prog-wrapper: New file. This additionally needs a modification of gnulib-tool: 2007-03-05 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_get_automake_snippet): Don't synthesize an EXTRA_lib_SOURCES augmentation for the relocatable-prog-wrapper module. *** gnulib-tool 4 Feb 2007 19:09:25 - 1.221 --- gnulib-tool 6 Mar 2007 03:17:07 - *** *** 1008,1019 # If some .c file exists and is not used with AC_LIBOBJ - for example, # a .c file is preprocessed into another .c file for BUILT_SOURCES -, # automake will generate a useless dependency; this is harmless. ! sed_extract_c_files='/\.c$/p' ! extra_files=`echo "$extra_files" | sed -n -e "$sed_extract_c_files"` ! if test -n "$extra_files"; then ! echo "EXTRA_lib_SOURCES +=" $extra_files ! echo ! fi ;; esac } --- 1008,1024 # If some .c file exists and is not used with AC_LIBOBJ - for example, # a .c file is preprocessed into another .c file for BUILT_SOURCES -, # automake will generate a useless dependency; this is harmless. ! case "$1" in ! relocatable-prog-wrapper) ;; ! *) ! sed_extract_c_files='/\.c$/p' ! extra_files=`echo "$extra_files" | sed -n -e "$sed_extract_c_files"` ! if test -n "$extra_files"; then ! echo "EXTRA_lib_SOURCES +=" $extra_files ! echo ! fi ! ;; ! esac ;; esac }
an stdio fix
The substitute is not self-contained if the 'snprintf' or 'vsnprintf' module is used: it is lacking a definition of size_t. 2007-03-05 Bruno Haible <[EMAIL PROTECTED]> * lib/stdio_.h: Include . *** lib/stdio_.h21 Feb 2007 02:18:10 - 1.1 --- lib/stdio_.h6 Mar 2007 03:17:11 - *** *** 29,34 --- 29,35 #include @ABSOLUTE_STDIO_H@ #include + #include /* The definition of GL_LINK_WARNING is copied here. */
frexpl, ldexpl declarations
POSIX specifies [1] that should declare frexpl() and ldexpl() but neither glibc not MacOS X 10.3 do so. (Paul, do you agree that it looks like a glibc bug?) Here is a cheap workaround for the 'printf-frexpl' module. 2007-03-05 Bruno Haible <[EMAIL PROTECTED]> * m4/printf-frexpl.m4 (gl_FUNC_PRINTF_FREXPL): Also test whether frexpl and ldexpl are declared. * lib/printf-frexp.c (frexpl, ldexpl): Provide fallback declarations. *** m4/printf-frexpl.m4 3 Mar 2007 13:57:24 - 1.1 --- m4/printf-frexpl.m4 6 Mar 2007 03:31:34 - *** *** 1,4 ! # printf-frexpl.m4 serial 1 dnl Copyright (C) 2007 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, --- 1,4 ! # printf-frexpl.m4 serial 2 dnl Copyright (C) 2007 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, *** *** 23,28 --- 23,31 if test $gl_cv_func_frexpl_no_libm = yes; then AC_DEFINE([HAVE_FREXPL_IN_LIBC], 1, [Define if the frexpl function is available in libc.]) + dnl Also check whether it's declared. glibc (2.3..2.5 at least) and + dnl MacOS X 10.3 have frexpl() in libc but don't declare it in . + AC_CHECK_DECLS([frexpl]) fi AC_CACHE_CHECK([whether ldexpl can be used without linking with libm], *** *** 38,43 --- 41,49 if test $gl_cv_func_ldexpl_no_libm = yes; then AC_DEFINE([HAVE_LDEXPL_IN_LIBC], 1, [Define if the ldexpl function is available in libc.]) + dnl Also check whether it's declared. glibc (2.3..2.5 at least) and + dnl MacOS X 10.3 have ldexpl() in libc but don't declare it in . + AC_CHECK_DECLS([ldexpl]) fi fi ]) *** lib/printf-frexp.c 25 Feb 2007 18:08:24 - 1.3 --- lib/printf-frexp.c 6 Mar 2007 03:31:34 - *** *** 41,46 --- 41,54 # define USE_FREXP_LDEXP # define FREXP frexpl # define LDEXP ldexpl + /* glibc (2.3..2.5 at least) and MacOS X 10.3 have frexpl and ldexpl in +libc, but don't declare them. */ + # if !HAVE_DECL_FREXPL + extern long double frexpl (long double, int *); + # endif + # if !HAVE_DECL_LDEXPL + extern long double ldexpl (long double, int); + # endif # endif # define L_(literal) literal##L # else [1] http://www.opengroup.org/susv3/basedefs/math.h.html
Re: frexpl, ldexpl declarations
Bruno Haible <[EMAIL PROTECTED]> writes: > POSIX specifies [1] that should declare frexpl() and ldexpl() but > neither glibc not MacOS X 10.3 do so. (Paul, do you agree that it looks like > a glibc bug?) Yes, math.h should declare them as functions. But are you sure it isn't already doing this somehow? It works for me, with Debian stable: $ cat t.c #include $ /usr/bin/c99 -E t.c | grep -wE 'frexpl|ldexpl' extern long double frexpl (long double __x, int *__exponent) ; extern long double __frexpl (long double __x, int *__exponent) ; extern long double ldexpl (long double __x, int __exponent) ; extern long double __ldexpl (long double __x, int __exponent) ;
Re: st_birthtime
"James Youngman" <[EMAIL PROTECTED]> writes: > I see that FreeBSD and NetBSD support st_birthtime. I'm considering > supporting these in findutils. Is there any interest in suporting > (i.e. maintaining if I contribute a patch) this in stat-time.h? Sure, might as well. Do they support st_birthtime with only a 1-second resolution, or is it really a nanosecond resolution in the header? > If there is interest in maintaining the feature, how should we handle > systems (like Linux) where this is not supported? By having the > caller of stat-stime.h inline functions check > HAVE_STRUCT_STAT_ST_BIRTHTIME itself? That would be easiest to implement, I guess. It doesn't make much sense to have a substitute value on platforms where st_birthtime was not available, so the caller would need to decide what to do.
Re: config.rpath conflict
Bruno Haible <[EMAIL PROTECTED]> writes: >> Any suggestions? > > The config.rpath in gnulib is newer than the one from the latest gettext > release (0.16.1). Therefore I would move build-aux/config.rpath away so > that autopoint doesn't see it, and then move it back. Ok, I have made the GNUmakefile etc do this for me now. I hope I don't have to do it for a long time... /Simon
