Re: Project management and code quality tools

Hi, Simon Josefsson <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: >> I think it is a really good idea. If the scripts are distributed in >> gnulib more GNU packages will be using them and improving them. > > Thanks for feedback, I have pushed the module into gnulib. That's good news!

Re: Generating code coverage reports

Hi, Simon Josefsson <[EMAIL PROTECTED]> writes: > build-coverage: > make CFLAGS=$(COVERAGE_OPTS) CXXFLAGS=$(COVERAGE_OPTS) VALGRIND= > make CFLAGS=$(COVERAGE_OPTS) CXXFLAGS=$(COVERAGE_OPTS) VALGRIND= check > mkdir -p doc/coverage > lcov --directory . --output-file doc/cove

Re: Generating code coverage reports

Hi Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hello Ludovic, Simon, > > * Ludovic Courtès wrote on Tue, Oct 28, 2008 at 05:48:12PM CET: >> >> Let me explain this. Suppose you have tests T1 and T2: >> >> * T1 uses code from foo.c and t1.c;

Re: Generating code coverage reports

Hi Simon, Simon Josefsson <[EMAIL PROTECTED]> writes: > +COVERAGE_CCOPTS ?= "-g -fprofile-arcs -ftest-coverage" Looks to me that `--coverage' is more appropriate as it adds all `-f' options that are needed, so it's potentially more "future-proof". Also, LDFLAGS must be modified to do either `-l

Re: Generating code coverage reports

Simon Josefsson <[EMAIL PROTECTED]> writes: > Yes, but it seems that --coverage is passed to the command line to link > applications with CFLAGS: > > [EMAIL PROTECTED]:~/src/libidn/src master$ rm idn > [EMAIL PROTECTED]:~/src/libidn/src master$ make CFLAGS="-g --coverage" > make all-am > make[1]:

Re: Generating code coverage reports

Hi Simon, Simon Josefsson <[EMAIL PROTECTED]> writes: > Hi Ludovic. Thanks, I pushed this patch. Adding anything to LDFLAGS > doesn't seem to be required though? According to the doc (info "(gcc)Debugging Options") it is required. See also this example (with GCC 4.2.4): $ cat > t.c < Btw, i

Re: [gnu-prog-discuss] url's in --help output

Hello, Simon Josefsson writes: > I suggest a new gnulib module emit-bug-reporting-address. I have the > following code in GNU Libidn, which is strongly influenced by GNU > CoreUtils. Removing the 'static' keyword and putting it in a gnulib > module would make it easy to re-use the code, and po

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: >> Is there any reason this cannot be made part of `version-etc'? > > No reason. It seems like a better place actually. Jim, how about this > patch? And while we're at it, can't `versio

License inconsistency for `verify'

Hello, The `verify' module appears as LGPLv2+-licensed but says GPLv3+. Commit b6f8b81b changed the license from LGPL to LGPLv2+, so I suppose it's the header that's incorrect. Am I right? Thanks, Ludo'.

Re: License inconsistency for `verify'

Hello, Bruno Haible writes: > Ludovic Courtès wrote: >> The `verify' module appears as LGPLv2+-licensed but says >> GPLv3+. > > This is normal. See the README, section "License", or the manual [1]. Thanks for the clarification. Is it just out of conveni

Broken isnan(3) and/or DQNAN on Tru64

Hello, On `alphaev56-dec-osf5.1b', NaN handling seems to be deeply broken. Consider this piece of code: --8<---cut here---start->8--- #include extern unsigned int DQNAN[2]; int main (int argc, char *argv[]) { return isnan (* (double *) DQNAN); } --8<--

Re: Broken isnan(3) and/or DQNAN on Tru64

Hi Bruno, Bruno Haible writes: > What's the result when you compile it with cc? > $ cc foo.c -lm > $ ./a.out > $ echo $? 1 That's with "Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)". Should we conclude that this is a GCC bug? I'll try with different versions. > What'

Re: Broken isnan(3) and/or DQNAN on Tru64

Hello, Bruno Haible writes: > I meant %08X instead of %04X. DQNAN therefore likely is > FFF8 > which decomposes into > sign = 1 (irrelevant for NaNs), > exponent = 0x7FF (highest possible value) > mantissa = 0x8 > and this is precisely the common encoding of a qui

Re: Broken isnan(3) and/or DQNAN on Tru64

Hi, Bruno Haible writes: >> So people compiling with GCC on this platform should pass `-mieee' >> (`configure' could add it automatically.) > > The gnulib module 'fpieee' adds it automatically. This module appears to be overzealous: `gl_FP_IEEE' just checks for the host CPU, but on alpha*-linux

Re: Broken isnan(3) and/or DQNAN on Tru64

l...@gnu.org (Ludovic Courtès) writes: > Or maybe that's a Debian patch that enables `-mieee' by default? Actually yes, there's `debian/patches/alpha-ieee.dpatch', which is why I didn't observe SIGFPEs on Debian GNU/Linux. Ludo'.

have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

Hello, When passed ‘--with-PACKAGE-prefix=/p’, ‘AC_LIB_LINKFLAGS_BODY’ deduces ‘additional_libdir=/p/lib64’ on x86_64. This doesn’t work on NixOS which doesn’t (quite) support multilib, and where libs are to be found under ‘/p/lib’. Unfortunately, this leads ‘AC_LIB_LINKFLAGS_BODY’ to ignore the

Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

Hi Bruno, Bruno Haible writes: > You can just as well set CPPFLAGS and LDFLAGS manually, then. Recall that > the --with-PACKAGE-prefix option is merely a shortcut for what can > be specified by setting CPPFLAGS and LDFLAGS appropriately. Right. > This will placate the real problem. The real pr

getopt compilation failure on Darwin (gzip 1.3.13)

Hello, (Cc’ing ‘bug-gnulib’ as this looks like a Gnulib issue.) GNU zip 1.3.13 fails to build on Darwin: --8<---cut here---start->8--- gcc -std=gnu99 -DHAVE_CONFIG_H -I. -g -O2 -c getopt.c In file included from ./getopt.h:28, from getopt.h

Re: getopt compilation failure on Darwin (gzip 1.3.13)

Hi Eric, Eric Blake writes: > The circle was: > ./getopt.h did include_next > did include , but found ./unistd.h > ./unistd.h did include_next >completed > ./unistd.h did include , and found ./getopt.h >./getopt.h declared things > ./unistd.h completed > redeclared things > >

Explicit interpreter paths considered harmful

Hello, A number of maintainer scripts explicitly use ‘#!/usr/bin/perl’ or similar, but not all systems have Perl at this location (distros such as NixOS and GoboLinux don’t have it there, and users in general are free to install it elsewhere anyway.) Of course it’d be unreasonable to have ‘AC_PAT

Re: Explicit interpreter paths considered harmful

Hi, Paolo Bonzini writes: >> --- a/build-aux/gitlog-to-changelog >> +++ b/build-aux/gitlog-to-changelog >> @@ -1,4 +1,7 @@ >> -#!/usr/bin/perl >> +#!/bin/sh >> +# Accommodate systems where /usr/bin/perl is not the right path. >> +exec perl -x "$0" "$@" >> +#!perl >> >> The only assumption it mak

Re: Explicit interpreter paths considered harmful

Hello, Jim Meyering writes: > However, is this really necessary? > You're not running gitlog-to-changelog manually, are you? > If it's scripted, you can easily invoke it via "perl gitlog-to-changelog ..." True, but then among the scripts under ‘build-aux’, some are invoked directly by ‘maint.mk

Re: Explicit interpreter paths considered harmful

Hi Karl, k...@freefriends.org (Karl Berry) writes: > -#!/usr/bin/perl > +#!/bin/sh > > Just to mention that an alternative would be #!/usr/bin/env perl. It won’t work on NixOS, which doesn’t have /usr/bin. (On NixOS, the only “standard” path that can be relied on is /bin/sh.) Thanks, L

Re: Explicit interpreter paths considered harmful

Paolo Bonzini writes: > Yeah. But why not the standard > > #! /bin/sh > eval 'exec /usr/bin/perl -S $0 ${1+"$@"}' > if 0; > > suggested in perlrun(1)? Actually that doesn’t work: --8<---cut here---start->8--- $ ./build-aux/gitlog-to-changelog /bin/sh:

Re: Explicit interpreter paths considered harmful

Here's a patch. Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to do here: - ‘gl_PMCCABE2HTML’ does ‘AC_PROG_AWK’, so we could substitute @AWK@ in there. - OTOH, ‘pmccabe2html’ is typically a maintainer script, so I’d rather remove ‘AC_PROG_AWK’ and do something

Reliance on

Hi, I just noticed that Gnulib modules rely on the availability of a `#include'able file. I'm using Gnulib in a project that does: AC_CONFIG_HEADER([some-special-name.h]) There, Gnulib modules fail to compile because is not available. I'd happily work around this by doing something like:

Re: Reliance on

Hi, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Another possibility is to generate lib/config.h.in from > some-special-name.h.in, say, by some sed script or an autoheader > invocation with arguments and output redirection. Good point. I ended up using `AC_CONFIG_LINKS' to have a `config.h' li

Re: second call: please nail down the license terms of some more modules

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Yoann Vandoorselaere wrote: >> don't you think this could be a show stopper to early GnuLib adopters? > > No, I don't think so. Projects which have been using already cannot have > missed the long thread here; projects which will adopt it in the futu

Minor glitches with `announce-gen'

Hi, The `NEWS' parsing routine in `announce-gen' seems to be over-specified in that it expects lines introducing a new version to match "\* (?:Noteworthy|Major) change". AFAICS, this is not too common practice among GNU packages: GnuTLS uses "* Version X.Y.Z (released -MM-DD)", Guile uses "Ch

Author list in `version-etc'

Hi, Currently, `version_etc_va ()' disallows empty author lists. The GCS do not mandate it and it can be arguably useful to not list any authors (e.g., in projects with large `THANKS'). Can the `abort ()' and extraneous newlines be removed? Thanks, Ludovic. PS: I could submit the actual patch

Multiply exported Gnulib symbols

Hi, The following issue was brought up recently on the Guile list [0]. Suppose some library uses, e.g., the `strcasecmp' module, which exports `strcasecmp ()' (assuming the module is actually compiled). Suppose, for instance, that an application using said library is also linked against `strcase

Updated user list

Hi, The attached patch adds Guile (1.9.x) to the user list. Thanks, Ludovic. diff --git a/ChangeLog b/ChangeLog index d780a41..54fa517 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2007-08-22 Ludovic Courtès <[EMAIL PROTECTED]> + + * users.txt: Added Guile. + 2007-08-22 Eric

Re: Multiply exported Gnulib symbols

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Three possible issues are known: > > 1) guile defining (via gnulib) a symbol called 'strcasecmp', which overrides >the libc's strcasecmp symbol for libraries that come after libguile in the >executable's link list or are dynamically loaded. >

Re: Reliance on

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > >> Another possibility is to generate lib/config.h.in from >> some-special-name.h.in, say, by some sed script or an autoheader >> invocation with arguments and output r

Endianness-specific

Hi, I'm trying to implement functions that convert a string in the current locale encoding to its UTF-{16,32} representation, for a given endianness. `u16-conv-from-enc.c' reads this: /* Name of UTF-16 encoding with machine dependent endianness and alignment. */ #if defined _LIBICONV_VERSI

Endianness-aware UTF conversion

Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> writes: > Therefore I would recommend to use the mem_cd_iconveh function from the > 'striconveh' module, with FROMCODE = locale_charset() and TOCODE = > "UTF-16BE" or "UTF-16LE" (or vice versa). Or mem_iconveh you don't > want to reuse the conversion des

Re: new module iconv_open-utf

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Yes, it is clear what you mean. But adding a new API for a thing that > mem_cd_iconveh should be able to do, just because there is a portability > problem, is against gnulib's general approach. In gnulib we solve this > by fixing the portability prob

Re: Gnulib Gentoo package

Hi Sylvain, Sylvain Beucler <[EMAIL PROTECTED]> writes: > I noticed 2 issues in your Gnulib Gentoo package: Thanks for finding it out! Ludovic.

Re: inline related build failures on MacOS X 10.5

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > $ gcc -v 2>&1 | tail -1 > gcc version 4.0.1 (Apple Inc. build 5465) > > It appears to be a GCC 4.0.x with some backports from the GCC 4.2 and 4.3 > development. > > For 'extern inline', this gcc generates a symbol with global visibility in > "gcc

Re: stdarg: don't put compiler in gnu99 mode by default

Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> writes: > + #ifdef __GNUC_STDC_INLINE__ > + #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ > ((__gnu_inline__)) Unfortunately that doesn't work on MacOS X because Apple's GCC (labeled "4.0") implements C99 inline semantics but 1. Does n

Re: inline related build failures on MacOS X 10.5

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > 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 y

Re: stdarg: don't put compiler in gnu99 mode by default

Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> writes: > The #ifdefs for determining which variant of 'inline' or 'extern inline' > don't work any more with the Apple GCC compiler on MacOS X. FWIW, I had reported these issues too: http://thread.gmane.org/gmane.comp.lib.gmp.bugs/1979 I can't find

Re: stdarg: don't put compiler in gnu99 mode by default

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Oh, sorry for the duplicate report. Your report does not appear in > http://lists.gnu.org/archive/html/bug-gmp/ > whereas mine does. And your report appears on gmane, but mine doesn't. > Are these two different maiing lists?? The Gmane list appears

Re: symbol namespace collisions

Hello, Simon Josefsson <[EMAIL PROTECTED]> writes: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> Also, the memrchr module does not support the renaming in config.h that >> is used to guarantee namespace cleanliness of shared libraries. E.g. >> #define memrchr libfoo_memrchr > > Interesting, a

Re: gnulib-cache.m4 readability

Hi, Eric Blake <[EMAIL PROTECTED]> writes: > On m4, I'm currently playing with multiple branches, each of which has > imported > a different set of gnulib modules via 'gnulib-tool --import'. I'm finding it > very difficult to track which modules have been imported to which branches by > usin

`count-one-bits' -> LGPLv2+

Hi, Would you be OK to relicense `count-one-bits' under LGPLv2+ for use in Guile 1.9 (aka. the development branch)? Thanks, Ludovic.

Re: `count-one-bits' -> LGPLv2+

Hi, Eric Blake <[EMAIL PROTECTED]> writes: > As author, you are entitled to make that change. And I agree that > count-one-bits is library quality (since it can often be a thin wrapper > around a special assembly instruction). So I went ahead and pushed this > commit: Thanks! Ludo'.

`nstrftime ()' prototype

Hi, I'm trying to fix a portability bug related to `strftime(3)' [0]. The `strftime' module doesn't provide `strftime ()' as one would expect but instead provides `nstrftime ()', with additional arguments: int ut, int ns. What are these arguments about? Thanks, Ludovic. [0] https://savannah.gn

Re: `nstrftime ()' prototype

Hi Simon, Simon Josefsson <[EMAIL PROTECTED]> writes: > That doesn't make much sense to me. IMHO, the 'strftime' module should > provide a 'strftime' function. Agreed. IIUC, this could be achieved by compiling the file twice: once with "#define my_strftime" and once without. > Where is 'nstrf

Re: `nstrftime ()' prototype

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Ludovic Courtès wrote: >> I'm trying to fix a portability bug related to `strftime(3)' [0]. The >> `strftime' module doesn't provide `strftime ()' as one would expect > > And the gnulib doc is in

Re: `nstrftime ()' prototype

Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> writes: > Ludovic Courtès wrote: >> In addition, it doesn't mention any portability problem, but AIX and >> Solaris (at least) have a non-C99-compliant behavior (let alone GNU >> extensions): https://savannah.gnu.org/bu

Re: `nstrftime ()' prototype

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > I'm trying to fix a portability bug related to `strftime(3)' [0]. The > `strftime' module doesn't provide `strftime ()' as one would expect but > instead provides `nstrftime ()', with additional argum

Re: `nstrftime ()' prototype

Hi, Jim Meyering <[EMAIL PROTECTED]> writes: > Here's some long-overdue documentation: > > From 4bb481aef2793a2cd25d61113d58da42af2bf8a8 Mon Sep 17 00:00:00 2001 > From: Jim Meyering <[EMAIL PROTECTED]> > Date: Sun, 31 Aug 2008 17:34:24 +0200 > Subject: [PATCH] * lib/strftime.h: Add comments desc

Re: `nstrftime ()' prototype

Hi again, Jim Meyering <[EMAIL PROTECTED]> writes: > +/* Just like strftime, but with two more arguments: > + POSIX requires that strftime use the local timezone information. > + When __UTC is nonzero and tm->tm_zone is NULL or the empty string, > + use UTC instead. Use __NS as the number

[PATCH] Use `AC_C_RESTRICT' in `time'

Hi, The following patch makes sure `time' uses `AC_C_RESTRICT'. This fixes compilation at least on MinGW as reported here: http://thread.gmane.org/gmane.lisp.guile.bugs/3984 Thanks, Ludovic. >From 06dc37c4ee56e9d32bfcb79ace9221c903ade7b2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Ludovic=20Cou

Re: [PATCH] Use `AC_C_RESTRICT' in `time'

Hi, Eric Blake <[EMAIL PROTECTED]> writes: > Could it also be a case of not including before system headers? You're probably right. I'm waiting for a confirmation... Thanks, Ludo'.

nproc -> LGPL

Hello! I’d like to use ‘nproc’ in libguile, which is LGPLv3+. Could you change the license accordingly? Thanks, Ludo’.

Re: nproc -> LGPL

Bruno Haible writes: > Glen Lenker wrote: >> > Glen, do you also agree with Ludo's request? >> >> It is fine with me; nproc is quite libraryish. > > OK, I've pushed the license change. Great, thanks! Ludo’.

unistr use of undefined macros

Hello, Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a side-effect, this prevents compilation of users of this file, such as Guile, with ‘-Wundef’: --8<---cut here---start->8--- In file included from bytevectors.c:43:0: ../lib/unistr.h:161:5: erro

Re: unistr use of undefined macros

Hi Eric, Eric Blake writes: > On 12/07/2010 02:24 PM, Ludovic Courtès wrote: >> Hello, >> >> Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a >> side-effect, this prevents compilation of users of this file, such as >> Guile, with ‘-Wundef’: > &

Re: PATH_MAX and test-stat.h

Hello, k...@freefriends.org (Karl Berry) skribis: > I am aware that conceptually there is no PATH_MAX on Hurd and no > requirement for it to be a smallish constant, but it seems to me that > any real-world system has to define PATH_MAX as a reasonable constant > simply for compatibility with all

getaddrinfo on MinGW

Hello, The ‘getaddrinfo’ module doesn’t seem to work as advertised ;-) when cross-building for MinGW. >From , a file that includes Gnulib’s fails to build like this: --8<---cut here---start->8--- /bin/sh ../libtool --tag

‘iconv’ fails to build on NetBSD 5.1

Hi, The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC Compile Farm): --8<---cut here---start->8--- depbase=`echo iconv.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/ksh ../libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I../.

Re: ‘iconv’ fails to build on NetBSD 5.1

Hi Bruno, Bruno Haible skribis: >> The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC >> Compile Farm): > > Can you show the gnulib-tool invocations that you used when builting > the tarball of your package? In particular, which of the modules > 'iconv', 'iconv-h', 'iconv_ope

Re: Explicit interpreter paths considered harmful

s search path. > * build-aux/gitlog-to-changelog: Replace #!... as above. > Add a "Local Variables" perl mode setting. > Prompted by a patch from Ludovic Courtès. > Improved by Eric Blake. Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl gitlog-to-cha

Re: Explicit interpreter paths considered harmful

Hi Simon, Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Here's a patch. >> >> Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to >> do here: > > See the documentation in pmccabe2html -- the recommended way t

Re: Explicit interpreter paths considered harmful

Excellent, thank you all! Ludo’.

‘version-etc’ licensing and API

Hello, I’d like to use ‘version-etc-fsf’ in Guile 1.9+ (for the main executable), but Guile is LGPLv3+. Would it be possible to change the license accordingly? Besides, ‘version_etc_arn ()’ currently reads this: --8<---cut here---start->8--- switch (n_autho

Re: ‘version-etc’ licensing and API

Hi Jim, Jim Meyering writes: > Ludovic Courtès wrote: >> I’d like to use ‘version-etc-fsf’ in Guile 1.9+ (for the main >> executable), but Guile is LGPLv3+. Would it be possible to change the >> license accordingly? > > Sure. Done. Thanks. Can you also change ‘version-etc-fsf’? Ludo’.

[PATCH] Add ‘gnulib-tool’ support for LGPLv3+

Hello, The attached patch fixes LGPLv3+ support in ‘gnulib-tool’. Thanks, Ludo’. From 29c308aa797c07f9cc40074338ae6b5e5a290be8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Tue, 17 Nov 2009 21:38:51 +0100 Subject: [PATCH] Add `gnulib-tool --import' support for LGPLv3+.

Re: usleep

Hi, Eric Blake writes: > +unsigned int > +rpl_sleep (unsigned int seconds) > +{ > + const unsigned int limit = 49 * 24 * 60 * 60; > + while (limit < seconds) > +{ > + seconds -= limit; > + unsigned int result = sleep (limit); This declaration-after-statement is a C99 thing. Isn

Re: new module 'duplocale'

Hi Bruno, Bruno Haible writes: > glibc unfortunately has a big bug in its duplocale function: > > This module provides a workaround for it. Tested on glibc and MacOS X systems, > which are AFAIK the only systems so far with a duplocale fun

Re: new module 'duplocale'

Hi, Eric Blake writes: > According to Ludovic Courtès on 11/23/2009 4:01 PM: >>> const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE)); >> >> This is not thread-safe but I guess there’s no other choice. > > As is the case with a number of gnulib mo

Re: new module 'duplocale'

Hi Bruno, Bruno Haible writes: >> > const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE)); >> >> This is not thread-safe but I guess there’s no other choice. > > This code is only used on glibc systems, and nl_langinfo is multithread-safe > on glibc systems (by code inspection

stdbool issue on Solaris 8 with SunStudio 11

Hello, Libunistring 0.9.1 fails to build on Solaris with Sun cc and Sun make: --8<---cut here---start->8--- rm -f unistring/stdbool.h-t unistring/stdbool.h { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ echo '#if !defined _GL_STDBOOL_H'; \ if test

Re: coreutils-8.2 bug-fix-only release coming soon

Hello, FWIW the Hydra build farm at TU Deflt[*] now continuously builds Coreutils from Git using Gnulib from Git[+]: http://hydra.nixos.org/jobset/gnu/coreutils-master http://hydra.nixos.org/jobset/gnu/coreutils-master/all Currently 6 of 355 tests fail on GNU/Linux (this could be due to file

Re: [bug-libunistring] stdbool issue on Solaris 8 with SunStudio 11

Hi Bruno, Bruno Haible writes: > This was a packaging bug in libunistring-0.9.1, and is fixed in > libunistring-0.9.1.1. Indeed, thanks. FYI the Hydra build farm at TU Deflt[*] now continuously builds libunistring from Git using Gnulib from Git on 3 different platforms: http://hydra.nixos.o

GNU Patch 2.6.1 fails to build on Darwin

Hello, Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]: --8<---cut here---start->8--- gcc -std=gnu99 -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/nix/store/1dk6yj85f9j1manfrd3001az2r7ggb8n-ed-1.4/bin/ed\" -DENABLE_MERGE -I. -I./src -I./gl/lib -g -O2 -o gl/

Re: new snapshot available: coreutils-8.2.52-4db2f

Hi Jim, Jim Meyering writes: > Ludovic Courtès wrote: >> Surprisingly “make dist” has been failing on Hydra for some time[*]: >> >> gcc -std=gnu99 -I. -g -O2 -c -o exclude.o exclude.c >> In file included from mbuiter.h:106, >> from exclu

Re: [bug-patch] GNU Patch 2.6.1 fails to build on Darwin

Hi Andreas, Sorry for the late reply. Andreas Gruenbacher writes: > On Monday 11 January 2010 02:45:41 pm Ludovic Courtès wrote: >> Hello, >> >> Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]: > > does the latest version on ftp://alpha.gnu.org/gnu/p

Bogus getaddrinfo(3) on Darwin 9.2.2

Hello! The getaddrinfo(3) function appears to have bogus behavior on ‘i386-apple-darwin9.2.2’ (Darwin 9.6 apparently doesn’t have the problem). Here’s the test program: --8<---cut here---start->8--- #include #include #include #include int main (int argc,

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

Hi Simon, Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Hello! >> >> The getaddrinfo(3) function appears to have bogus behavior on >> ‘i386-apple-darwin9.2.2’ (Darwin 9.6 apparently doesn’t have the >> problem). Here’s the test

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

l...@gnu.org (Ludovic Courtès) writes: > #include > #include > #include > #include > > int > main (int argc, char *argv[]) > { > int err; > struct addrinfo *res, hints; > > memset (&hints, 0, sizeof (hints)); > err = getaddrinfo (NULL, "

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> What I meant to say is that it should return an error because resolving >> the ‘does-not-exist’ service fails. > > Does it only fail (well, falsely succeed) for unknown services? When asked for a

NetBSD 5.0’s lacks AI_* macros

Hello, NetBSD 5.0’s doesn’t define ‘AI_ALL’, ‘AI_V4MAPPED’, and ‘AI_ADDRCONFIG’. This can be worked around with something like this: #ifndef AI_ALL # define AI_ALL 0 #endif #ifndef AI_V4MAPPED # define AI_V4MAPPED 0 #endif #ifndef AI_ADDRCONFIG # define AI_ADDRCONFIG 0 #endif

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

l...@gnu.org (Ludovic Courtès) writes: > l...@gnu.org (Ludovic Courtès) writes: > >> #include >> #include >> #include >> #include >> >> int >> main (int argc, char *argv[]) >> { >> int err; >> struct addrinfo *res, hints;

Re: NetBSD 5.0’s lacks AI_* macros

Hi, Simon Josefsson writes: > Thanks, fixed as below. Note that _support_ for these symbols is not > required by POSIX (it is conditional on IPv6 support), but the symbols > are required to be defined. So this is a bug in NetBSD netdb.h and > should be reported. Right. Thanks! Ludo’.

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

Hi, Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Simon Josefsson writes: >> >>> l...@gnu.org (Ludovic Courtès) writes: >>> >>>> What I meant to say is that it should return an error because resolving >>>> t

Re: [PATCH] lib/malloca.c, lib/md5.c, lib/sha1.c: don't include unless HAVE_CONFIG_H is defined

Hi, Simon Josefsson writes: > Peter Simons writes: > >> The following patches are necessary to make those modules compile in >> projects that don't use a header. > > That is generally not supported by gnulib. The majority of code in > gnulib assumes there is a config.h already; >95% if my gre

Re: gnulib module install

Hi, Simon Josefsson writes: > k...@freefriends.org (Karl Berry) writes: > >> What I mean - I wouldn't mind commiting gnulib stuff to VCS, but only >> if I can omit files generated by autoreconf. >> >> FWIW, that is exactly what I do for Texinfo. It helps my contributors >> to not spend

Re: C++ libtool build error?

Hello, Simon Josefsson writes: > Recently gnulib added some self-tests written in C++ for otherwise > C-only modules. When imported into libidn (otherwise a strictly C > library), this leads to an error message: > > /bin/bash ../libtool --preserve-dup-deps --mode=link g++ -o > test-fcntl-

iconv_open: Build failure with gperf 2.7.2

Hello, The ‘-m’ gperf option used by the ‘iconv_open’ module isn’t available in the ancient gperf 2.7.2: --8<---cut here---start->8--- Making all in lib rm -f alloca.h-t alloca.h && { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; cat ../../lib/alloca.i

Re: iconv_open: Build failure with gperf 2.7.2

Hi Bruno, Bruno Haible writes: > Ludovic Courtès wrote: >> The ‘-m’ gperf option used by the ‘iconv_open’ module isn’t available in >> the ancient gperf 2.7.2: > > It is documented in gnulib's DEPENDENCIES file: Oops, right, I missed that. >> What should be do

Re: iconv_open: Build failure with gperf 2.7.2

Hi, Ralf Wildenhues writes: > * Ludovic Courtès wrote on Mon, Mar 15, 2010 at 10:13:45AM CET: >> Surprisingly, using BSD make (on FreeBSD) it tries to run gperf, whereas >> using GNU make it doesn’t try to (for the same build tree on the same >> machine). Ideas? >

‘pty’ module fails on FreeBSD 7.2

Hi Simon, [Adding bug-gnu...@gnu.org.] Simon Josefsson writes: > Simon Josefsson writes: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Next one is this (FreeBSD): >>> >>> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../lib

Re: ‘pty’ module fails on FreeBSD 7.2

Hi Ralf, Ralf Wildenhues writes: > * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET: >> checking whether forkpty is declared... no >> checking whether forkpty is declared... (cached) no > >> Looking at pty.m4, I’m wondering whether the second >> ‘AC

Re: ‘pty’ module fails on FreeBSD 7.2

Hi Simon, Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Hi Ralf, >> >> Ralf Wildenhues writes: >> >>> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET: >>>> checking whether forkpty is declared... no >&

Re: sys_ioctl, sys_select: fix link errors

Hi Bruno, Bruno Haible writes: > 2010-03-28 Bruno Haible > > Fix link errors on mingw. > * lib/sys_ioctl.in.h (ioctl): Fix declaration idiom. > * modules/sys_ioctl-tests (Makefile.am): Link test-sys_ioctl-c++ with > $(LIBSOCKET). > * modules/sys_select-tests (Mak

Re: sys_ioctl, sys_select: fix link errors

Hi Bruno, Bruno Haible writes: >> >* lib/sys_ioctl.in.h (ioctl): Fix declaration idiom. >> >> This patch appears to break Inetutils bootstrapping: >> >> http://hydra.nixos.org/build/335490 > > Thanks for the quick report. This should fix it. The fix is modeled after the > gettimeofday, f

Re: const local variables

Hello, Paul Eggert writes: > All other things being equal, we should be encouraging a functional > style in which most local variables and parameters are never modified > once set. Agreed. How about adding something along these lines in the GCS? Thanks, Ludo’.

  1   2   >