I wanted the functionality of file_name_concat, but without
the exit-on-failure bits. Here's the result:
New function: mfile_name_concat.
* lib/filenamecat.c (mfile_name_concat): New function, just like
file_name_concat, but return NULL upon failure rather than exiting
Eric Blake <[EMAIL PROTECTED]> wrote:
> 2007-08-07 Eric Blake <[EMAIL PROTECTED]>
>
> Move xstrtol messages into gnulib domain, when --pobase is used.
> * lib/xstrtol.h (_STRTOL_ERROR): Move messages out of macro...
> * lib/xstrtol-error.c (xstrtol_error): ...into new file.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric Blake wrote:
> I'm not sure how that works. Yes, my understanding is that libssl is a
> gnulib client, but then it seems like you should have been asking on the
> libssl list. I don't see wget listed in gnulib/users.txt; do we need to
> add an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Micah Cowan on 8/7/2007 6:50 PM:
>>> The use of ./configure --with-libssl-prefix= has stopped
>>> working; I did some investigating, and it appears that the following
>>> code is problematic:
>
> Not considering that I had no idea (yet) w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric Blake wrote:
> According to Micah Cowan on 8/7/2007 12:07 PM:
>> Hello,
>
>> I have recently become the maintainer for GNU Wget, which uses autoconf
>> and havelib, but currently not automake.
>
>> The use of ./configure --with-libssl-prefix=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Micah Cowan on 8/7/2007 12:07 PM:
> Hello,
>
> I have recently become the maintainer for GNU Wget, which uses autoconf
> and havelib, but currently not automake.
>
> The use of ./configure --with-libssl-prefix= has stopped
> working; I d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric Blake wrote:
> We will probably start seeing reports like this more frequently as gcc 4.3 is
> adopted, especially since gnulib projects tend to prefer std=gnu99 when a gcc
> compiler is detected. Can anyone think of a way to detect broken sy
Eric Blake wrote:
> the pair 'extern inline' that causes the problem. Are we stuck with just
> telling these users that they shouldn't upgrade gcc without also upgrading
> their headers, because the old headers are broken with the new gcc?
When gcc changed the semantics they also introduced the
Eric Blake wrote:
> Can anyone think of a way to detect broken system
> headers that were relying on 'extern inline', in such a way that we can make
> the gnulib wrapper headers nuke those troublesome declarations out of the
> headers?
[1] contains a test case.
How to modify the glibc headers,
If you aren't already aware, the (not-yet-released) gcc 4.3 is changing the
semantics of 'extern inline' functions to obey C99 semantics when called with
std=gnu99. The net result of this change is that functions declared in headers
that relied on the old gcc semantics to be inline-only will no
Eric Blake wrote:
> This patch implements a solution - move the translatable strings into a .c
> file, so that they are owned by gnulib's POTFILES.in and the actual
> [d]gettext
> call occurs within the library. It also moves the testsuite out of xstrtol.c
> into the tests directory, so that I
Hi Eric,
> Right now, './gnulib-tool --with-tests --test xstrtol' issues this warning
> when
> run on cygwin 1.5.24:
>
> gcc -DHAVE_CONFIG_H -I. -I../../gltests -I. -I../../gltests -I..
> -I../../gltests/.. -I../gllib -I../../gltests/../gllib -g -O2 -MT
> test-wchar.o -MD -MP -MF .deps/tes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ralf Wildenhues wrote:
> The AS_IF of Autoconf 2.61 will cause all m4_require'd/AC_REQUIRE'd
> macros to be expanded outside of the conditional.
>
> Hope that helps.
It certainly does, thanks!
- --
Micah J. Cowan
Programmer, musician, typesetting
Hello Micah,
* Micah Cowan wrote on Tue, Aug 07, 2007 at 08:07:03PM CEST:
>
> If I remove the first invocation of AC_LIB_HAVE_LINKFLAGS (within
> gnutls), the second one functions as it used to. If I leave it as you
> see it above, apparently shlibext and other vars somehow get the null
> value,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I have recently become the maintainer for GNU Wget, which uses autoconf
and havelib, but currently not automake.
The use of ./configure --with-libssl-prefix= has stopped
working; I did some investigating, and it appears that the following
co
My complaint about including translatable strings in xstrtol.h has still not
been resolved. The problem is that if you use the new ./gnulib-tool --pobase
option, you are assuming that all gnulib source files will belong to the gnulib
domain, using gettext.h's redefinition of gettext to dgettext
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>>> What does 'LGPL' mean? v2.1+ or v3.0?
>>
>> The day we switch gnulib's major part to v3.0, it will mean LGPLv3+.
>
> Ok.
>
>>> The above are/may be needed by
>>> GnuTLS, so I think it would be useful if the remain LGPLv2.1+.
>>
>> Then please mark the
Right now, './gnulib-tool --with-tests --test xstrtol' issues this warning when
run on cygwin 1.5.24:
gcc -DHAVE_CONFIG_H -I. -I../../gltests -I. -I../../gltests -I.. -
I../../gltests/.. -I../gllib -I../../gltests/../gllib -g -O2 -MT test-
wchar.o -MD -MP -MF .deps/test-wchar.Tpo -c -o test-wc
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > Note that the following modules are not yet marked as LGPLv2+. I don't know
>> > if you intended it like this.
>> > crypto/arcfour:LGPL
>> > crypto/arctwo:LGPL
>> > crypto/hmac-md5:LGPL
>> > crypto/hmac-sha1:LGPL
>> >
19 matches
Mail list logo
