On Fri, 24 Apr 2020 at 02:41, Bruno Haible wrote:
>
> We do not want to put 'progname' under LGPL license, because 'progname' is
> meant to be used in programs, not libraries, and for programs the GPL is
> the right license.
>
That makes sense.
But things have changed since 2013: Gnulib modules
Hi Reuben,
> On Mon, 30 Dec 2013 at 09:28, Reuben Thomas wrote:
>
> > On 30 December 2013 08:18, Reuben Thomas wrote:
> >
> >>
> >> On 30 December 2013 01:20, Paul Eggert wrote:
> >>
> >>> Reuben Thomas wrote:
> >>>
> It's been drawn to my attention that under some circumstances, gnulib
>
On Mon, 30 Dec 2013 at 09:28, Reuben Thomas wrote:
> On 30 December 2013 08:18, Reuben Thomas wrote:
>
>>
>> On 30 December 2013 01:20, Paul Eggert wrote:
>>
>>> Reuben Thomas wrote:
>>>
It's been drawn to my attention that under some circumstances, gnulib
fails
to include progna
On 30 December 2013 08:18, Reuben Thomas wrote:
>
> On 30 December 2013 01:20, Paul Eggert wrote:
>
>> Reuben Thomas wrote:
>>
>>> It's been drawn to my attention that under some circumstances, gnulib
>>> fails
>>> to include progname when it's needed
>>>
>>
>> That's documented here:
>>
>>
>> h
On 30 December 2013 01:20, Paul Eggert wrote:
> Reuben Thomas wrote:
>
>> It's been drawn to my attention that under some circumstances, gnulib
>> fails
>> to include progname when it's needed
>>
>
> That's documented here:
>
> http://www.gnu.org/software/gnulib/manual/html_node/error-
> and-prog
Reuben Thomas wrote:
It's been drawn to my attention that under some circumstances, gnulib fails
to include progname when it's needed
That's documented here:
http://www.gnu.org/software/gnulib/manual/html_node/error-and-progname.html
It's been drawn to my attention that under some circumstances, gnulib fails
to include progname when it's needed. When cross-compiling error.c (as
required by fstat) for mingw32, I get a link failure to _program_name
(presumably because of error_print_progname).
--
http://rrt.sc3d.org
On 04/26/2011 05:35 PM, Eric Blake wrote:
> * modules/linkat (Depends-on): Require getcwd-lgpl.
> * modules/renameat (Depends-on): Likewise.
6 and 7 were both pretty uncontroversial; I've now pushed them.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://
index ea162d1..36cd25f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2011-04-26 Eric Blake
+ linkat, renameat: add missing dependency
+ * modules/linkat (Depends-on): Require getcwd-lgpl.
+ * modules/renameat (Depends-on): Likewise.
+
tests: reduce dependencies
|6 ++
modules/pread |1 +
modules/pwrite |1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0b67363..e4a89bc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-08-28 Eric Blake
+
+ pread, pwrite: add missing
According to Bruno Haible on 2/8/2010 4:41 PM:
> Ah, now I see. Yes, in this case HAVE_DECL_OBSTACK_PRINTF is not set to 0, and
> GNULIB_OBSTACK_PRINTF is not set to 1.
>
> So the combined proposed patch would look like this:
>
>
> 2010-02-08 Eric Blake
> Bruno Haible
>
>
Eric Blake wrote:
> But something IS needed. If you use gnulib-tool, but not --with-tests, then
> nothing calls gl_FUNC_OBSTACK_PRINTF, which means that
> HAVE_DECL_OBSTACK_PRINTF
> is never set to 0, which causes compilation failures on non-glibc platforms
> because obstack_printf is no longe
Bruno Haible clisp.org> writes:
> > * modules/obstack-printf-posix (Depends-on): Add obstack-printf.
>
> This is not needed. The modules 'obstack-printf-posix' and 'obstack-printf'
> are two modules that use the same source code but different .m4 macros.
> There is no need for running gl_FUN
Hi Eric,
> obstack-printf-posix-tests had a dependency on obstack-printf-tests.
> Somehow in the conversion to caching, we no longer pick up implicit
> dependencies of tests on their main module (that is, obstack-printf-tests no
> longer implies obstack-printf).
Wheee... You are right. This im
Eric Blake byu.net> writes:
>
> I will be committing this. Somehow, the recent gnulib-tool caching changes
> exposed it (the missing dependency is real; I'm not sure why the old gnulib-
> tool imported obstack-printf, but the current version is correct in avoiding
it
I will be committing this. Somehow, the recent gnulib-tool caching changes
exposed it (the missing dependency is real; I'm not sure why the old gnulib-
tool imported obstack-printf, but the current version is correct in avoiding it
without this patch).
From: Eric Blake
Date: Mon, 8 Feb
Hi Ralf,
thanks for your advise. "-L../lib -lgnu" is already used in other
places. I am going to fix them too.
Cheers,
Giuseppe
Ralf Wildenhues writes:
> Hello Giuseppe,
>
> * Giuseppe Scrivano wrote on Thu, Dec 03, 2009 at 07:30:54PM CET:
>> something against this trivial patch?
>
> I have
Hello Giuseppe,
* Giuseppe Scrivano wrote on Thu, Dec 03, 2009 at 07:30:54PM CET:
> something against this trivial patch?
I haven't checked whether or not this is right, but if it is, then
> -LDADD = -L../libinetutils -linetutils
> +LDADD = -L../libinetutils -linetutils -L../lib -lgnu
write "-
p 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Thu, 3 Dec 2009 19:27:30 +0100
Subject: [PATCH] Add missing dependency to gnulib
---
ChangeLog |4
tests/Makefile.am |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLo
something against this trivial patch?
It fixes "make check".
Giuseppe
>From 48baa84f12699ff6b3ee50e2b2211cce503f08ca Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Thu, 3 Dec 2009 19:27:30 +0100
Subject: [PATCH] Add missing dependency to gnulib
---
ChangeLog
Martin Lambers wrote:
> the getpass-gnu module should depend on the fseeko module, just like the
> getpass module does.
>
> Martin
>
>
> diff --git a/modules/getpass-gnu b/modules/getpass-gnu
> index af493f9..92e2d79 100644
> --- a/modules/getpass-gnu
> +++ b/modules/getpass-gnu
> @@ -7,6 +7,7 @
Hi,
the getpass-gnu module should depend on the fseeko module, just like the
getpass module does.
Martin
diff --git a/modules/getpass-gnu b/modules/getpass-gnu
index af493f9..92e2d79 100644
--- a/modules/getpass-gnu
+++ b/modules/getpass-gnu
@@ -7,6 +7,7 @@ lib/getpass.c
m4/getpass.m4
Depe
Sylvain Beucler wrote:
> Missing dependency: I imported the 'relocatable-prog' module in an
> empty project. It lacked the 'alloca' module dependency (although it
> imported 'alloca-opt'):
>
> $ sh bootstrap
> + autoreconf --install --symlink
Hi,
Missing dependency: I imported the 'relocatable-prog' module in an
empty project. It lacked the 'alloca' module dependency (although it
imported 'alloca-opt'):
$ sh bootstrap
+ autoreconf --install --symlink --warnings=all
/usr/share/aclocal/smpeg.m4:13: warn
According to Simon Josefsson on 4/3/2007 4:22 AM:
> "Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
>> Hi Eric,
>>
>> Please either, indent patches so that gpg doesn't escape leading '-'
>> signs, or use S/MIME for attaching as separate gpg signature.
>
> I think you meant PGP/MIME (RFC3156), S/M
Eric Blake wrote:
> It appears you forgot to commit this?
Yes. Done now.
> > Depends-on:
> > math
> > + fpucw
>
> And is there any reason you are undoing the alphabetic sort, other than that
> is
> what the file used to have before my patch?
Yes, keeping the natural order makes it easier
Bruno Haible clisp.org> writes:
> > * modules/printf-frexpl (Depends-on): Depend on ldexpl.
>
> Thanks for the quick fix. But this is overkill: the module 'ldexpl' looks
> for the ldexpl() function also in libm, and printf-frexpl doesn't this test
> result.
>
> 2007-04-03 Bruno Haible cl
Eric Blake wrote:
> libtool: compile: gcc -std=gnu99 -I. -I../../gnu -I../intl -g2 -Wall
> -Werror -MT ldexpl.lo -MD -MP -MF .deps/ldexpl.Tpo -c ../../gnu/ldexpl.c
> -DDLL_EXPORT -DPIC -o .libs/ldexpl.o
> ../../gnu/ldexpl.c:29:20: isnanl.h: No such file or directory
> ...
> make[3]: *** [ldexpl.lo
Eric Blake wrote:
> In trying to use sprintf-posix in m4, I came across this:
>
> cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
> configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS
> If this token and others are legitimate, please use m4_pattern
Hi Simon,
On 3 Apr 2007, at 11:22, Simon Josefsson wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
Please either, indent patches so that gpg doesn't escape leading '-'
signs, or use S/MIME for attaching as separate gpg signature.
I think you meant PGP/MIME (RFC3156), S/MIME doesn't use P
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> Please either, indent patches so that gpg doesn't escape leading '-'
> signs, or use S/MIME for attaching as separate gpg signature.
I think you meant PGP/MIME (RFC3156), S/MIME doesn't use PGP at all,
but yes, I agree with the suggesti
Hi Eric,
Please either, indent patches so that gpg doesn't escape leading '-'
signs,
or use S/MIME for attaching as separate gpg signature. Either would
allow
feeding a saved copy of emails containing a diff to GNU patch (which
copes
well with consistent indentation)
On 3 Apr 2007, at 04
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/2/2007 9:34 PM:
> In trying to use sprintf-posix in m4, I came across this:
>
> cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
> configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In trying to use sprintf-posix in m4, I came across this:
cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS
If this token and others are legitimate, pl
Bruno Haible wrote:
If you got malloc/realloc #defined, it is certainly because you used
the modules 'malloc'/'realloc'.
Or I blindly accepted the recommendations of autoscan-2.60, which inserted
AC_FUNC_MALLOC
AC_FUNC_REALLOC
into configure.scan, and I didn't notice. D'oh!
And I don't un
Charles Wilson wrote:
> The allocsa module includes eealloc.m4 in its filelist -- but it doesn't
> "depend" on the eealloc module --
Right.
> this allows the LGPL allocsa module to
> avoid bringing in the GPL eealloc.h, so as not to run afoul of GPL.
The license question is secondary. The pri
The allocsa module includes eealloc.m4 in its filelist -- but it doesn't
"depend" on the eealloc module -- this allows the LGPL allocsa module to
avoid bringing in the GPL eealloc.h, so as not to run afoul of GPL.
If eealloc.m4's contributions to configure cause config.h to #define
malloc/real
37 matches
Mail list logo
