Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

* Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: > Ralf Wildenhues wrote: > > - Posix does not require IFS to be set upon script startup. It only > > requires > > that, if IFS is unset, word splitting ought to behave as if it were set to > > space, tab, and newline, in that order. Th

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: >> Ralf Wildenhues wrote: >> > - Posix does not require IFS to be set upon script startup. It only >> > requires >> > that, if IFS is unset, word splitting ought to behave as if it were set to >> > space, tab,

MD5 module license

Hi, The license of the MD5 module is documented as LGPLv2+, but the source headers say it's under the GPLv2+, and that it's part of the (LGPL) libc. What is the actual license? :) -- Sylvain

libposix

Hi, I saw the new 'libposix' branch and I was curious about it - how is it supposed to be used? Also, is there any relationship with http://libposix.sourceforge.net/ ? Cheers! -- Sylvain

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

* Jim Meyering wrote on Sun, Nov 07, 2010 at 12:22:13PM CET: > Ralf Wildenhues wrote: > > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: > >> Ralf Wildenhues wrote: > >> > - Posix does not require IFS to be set upon script startup. It only > >> > requires > >> > that, if IFS is unse

Re: MD5 module license

Sylvain Beucler writes: > Hi, > > The license of the MD5 module is documented as LGPLv2+, but the source > headers say it's under the GPLv2+, and that it's part of the (LGPL) > libc. > > What is the actual license? :) The gnulib modules file is the canonical place, which says LGPLv2+. For histo

Re: libposix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Salut Sylvain, Sylvain Beucler wrote: > I saw the new 'libposix' branch and I was curious about it - how is it > supposed to be used? The idea is to build a standalone library of posix compatible functions from gnulib that will make writing and porti

Re: libposix

On 11/07/10 04:18, Sylvain Beucler wrote: > Hi, > > I saw the new 'libposix' branch and I was curious about it - how is it > supposed to be used? Once functional, it generates an installable project. Client projects can test for the existence of libposix and quit if not present or not recent enou

Re: [PATCH] [html] Fix copy/paste bug: Use unique name for compiler warnings.

Thien-Thi Nguyen wrote: > * MODULES.html.sh: For compiler warnings, use name > `ansic_ext_compwarn' since `ansic_ext_misc' is already taken. Thanks. I've applied your patch. (With "git am -3", it applied cleanly.) Bruno

vasnprintf: support glibc 'I' flag

Hi, Just noticed that gnulib's vasnprintf function does not support the same flags as the underlying system. In particular, glibc's 'I' flag (that causes localized digits to appear in the output instead of ASCII digits - a feature used in Farsi and Indic languages) ought to be supported by vasnpri

Re: libposix

Hi Gary, On Sun, Nov 07, 2010 at 10:48:55PM +0700, Gary V. Vaughan wrote: > Sylvain Beucler wrote: > > I saw the new 'libposix' branch and I was curious about it - how is it > > supposed to be used? > > The idea is to build a standalone library of posix compatible functions > from gnulib that wil

Re: MD5 module license

On Sun, Nov 07, 2010 at 02:46:16PM +0100, Simon Josefsson wrote: > Sylvain Beucler writes: > > The license of the MD5 module is documented as LGPLv2+, but the source > > headers say it's under the GPLv2+, and that it's part of the (LGPL) > > libc. > > > > What is the actual license? :) > > The gn

Re: MD5 module license

Sylvain Beucler wrote: > > The gnulib modules file is the canonical place, which says LGPLv2+. For > > historical reasons the header file says GPLv2+. > > Hmmm, would it make sense to update the header (possible keeping the > historical part as a comment)? The header is updated automatically whe

error.c has an unnecessary dependency on "program_name"

It is fairly easy to fix, just make the definition weak and check for a NULL value before using it. OK to push? index ed9dba0..65f2d9d 100644 --- a/lib/error.c +++ b/lib/error.c @@ -106,7 +106,7 @@ char *strerror_r (); /* The calling program should define program_name and set it to the name

Re: libposix

On 11/07/10 10:45, Sylvain Beucler wrote: > That sounds good, and this also sounds like quite a change from the > current gnulib. Hi Sylvain, As you may be aware, configuring for a build can take up the bulk of the build time for a project. There is no intention of preventing projects from conti

Re: [PATCH 4/7] New module `libposix'.

On 10/12/10 13:43, Bruno Haible wrote: > Hi Gary, > >> Making libposix into a module makes life considerably easier. > > Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of > noinst_LIBRARIES. > > But I don't agree with putting the module list here. Who will keep it > u

Re: error.c has an unnecessary dependency on "program_name"

Bruce Korb wrote: > error.c has an unnecessary dependency on "program_name" No, it is not an "unnecessary" dependency. There is no portable way for code in a module to determine the name of the current program. Programs that use the 'error' module must define the program_name variable and assign i

Re: libposix - is it done yet?

On 10/10/10 09:00, Bruno Haible wrote: > Hi Bruce, > >> > href="http://www.woofiles.com/dl-208694-BfZFVR4K-libposix2010.10.05.tar.gz";>libposix-2010.10.05.tar.gz > >> The tarball rolls up to 2MB with these directories: >> >> libposix-2010.10.05/libposix/uniwidth >> libposix-2010.10.05/libposix/un

Re: [gnulib] printf for plibc

Hi Nils, Nils Durner wrote: > ich würde gerne die printf Implementierung von gnulib in plibc (libc für > Windows) kopieren, damit wir sie für GNUnet, GNU libextractor & Co > benutzen können. > Ist es für Dich okay, wenn ich Deinen Code in die der LGPL unterliegende > plibc kopiere? [Nils is askin

Re: error.c has an unnecessary dependency on "program_name"

On 11/07/10 12:40, Bruno Haible wrote: > No, this is not OK, for two reasons: > 1) It will cause a link error for all programs that define the > 'program_name' > variable, on all non-ELF platforms (mainly MacOS X and Woe32). Not having MacOS or Woe32, I couldn't know. > 2) Substituting

unprefixed header guards

As of now, here are the files that get installed via "libposix": $ find * -type f usr/local/lib/libposix.a usr/local/lib/libposix.so.0.0.0 usr/local/lib/libposix.la [[a mess of includes]] usr/local/libexec/libposix/pt_chown And here are the headers that do not prefix an "ifndef" with "_LIBPOSIX_"

Re: libposix - is it done yet?

Bruce Korb wrote: > Maybe first the tests need to be gotten working: > > FAIL: test-dprintf-posix2.sh > FAIL: test-fprintf-posix3.sh > > > >sh> exec > /bin/sh: line 5: 24795 Segmentation fault EXEEXT='' srcdir='../../tests' > LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR'

Re: [PATCH 4/7] New module `libposix'.

Bruce Korb wrote: > > Who will keep it > > up-to-date? The maintainable solution is to use `./posix-modules`. But how? > > Either ... > > b) Invoke ../posix-modules in the bootstrap script of the 'libposix' > > subdirectory. > > Or: > c) create a script that auto-replaces the Depends-on:

Re: error.c has an unnecessary dependency on "program_name"

Hi Bruce, > > 1) It will cause a link error for all programs that define the > > 'program_name' > > variable, on all non-ELF platforms (mainly MacOS X and Woe32). ... and HP-UX, which also is a non-ELF platform. > Not having MacOS or Woe32, I couldn't know. There is some code for determ

Re: unprefixed header guards

Bruce Korb wrote: > And here are the headers that do not prefix an "ifndef" > with "_LIBPOSIX_": > > $ ls -1 $(allbut usr/local/include/*.h - $( > > egrep -l '#ifndef _LIBPOSIX_' usr/local/include/*.h) ) > usr/local/include/arg-nonnull.h > usr/local/include/iconv_open-aix.h > usr/local/include/ico

Re: [gnulib] printf for plibc

Hi Bruno, okay, thanks a lot. Best, Nils

fdopendir failure on MacOS X with GNU tar 1.25

(This is following up on recent bug reports sent to bug-tar: . but it appears to be a gnulib bug so

Re: error.c has an unnecessary dependency on "program_name"

On 11/07/10 15:55, Bruno Haible wrote: >> Seg faulting is even less friendly. > > A seg fault is a very clear hint to the developer that he needs to fix up his > code. Which IMO is the only good solution if a programmer has not defined > program_name. But it would only be encountered if the progr