[EMAIL PROTECTED] (Bob Proulx) writes:
> While building coreutils on HP-UX 11.11 using the native hp c compiler
> I noticed that gnulib's gl_IGNORE_UNUSED_LIBRARIES causes --as-needed
> to be inadvertently used where it is not a valid option there. It
> does not actually break the coreutils build
* Bob Proulx wrote on Tue, Jun 20, 2006 at 01:44:23AM CEST:
>
> Should the stderr be captured and if non-zero in size also denote a
> failure?
That's usually too conservative. CVS Libtool's _LT_LINKER_OPTION takes
empty stderr as success, or a zero diff between a link without and with
the option
For past reference see:
http://lists.gnu.org/archive/html/bug-gnulib/2006-06/msg00119.html
While building coreutils on HP-UX 11.11 using the native hp c compiler
I noticed that gnulib's gl_IGNORE_UNUSED_LIBRARIES causes --as-needed
to be inadvertently used where it is not a valid option there.
Eric Blake wrote:
> I was wondering if it would be worth teaching gnulib-tool about all the files
> that `autoreconf --install' normally installs, and then updating those files
> from gnulib's repository as part of `gnulib-tool --update'.
Oops, that's far beyond what gnulib intends to be. gnulib
[EMAIL PROTECTED] (Karl Berry) wrote:
> > OK to apply? These are the last five references within gnulib where
> > we did not assume the existance of errno.
>
> unsetenv was synced from coreutils. Do we prefer errno consistency or
> syncing? Help?
Hi Karl,
We want both :-)
I've just fix
> OK to apply? These are the last five references within gnulib where
> we did not assume the existance of errno.
unsetenv was synced from coreutils. Do we prefer errno consistency or
syncing? Help?
Hi Eric,
Eric Blake wrote:
> I was wondering if it would be worth teaching gnulib-tool about all the files
> that `autoreconf --install' normally installs, and then updating those files
> from gnulib's repository as part of `gnulib-tool --update'. That way, ad hoc
> rules in various Makefile.m
In preparing m4-1.4.4b for release, I noticed that using the released version
of automake 1.9.6 installed quite a number of out-of-date files, all of which
could be found more up-to-date within gnulib, thanks to the cron jobs that keep
gnulib CVS up-to-date with the various upstream sources of t
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> @@ -78,10 +76,8 @@
>> {
>>switch (af)
>> {
>> -#if HAVE_IPV4
>> case AF_INET:
>>return (inet_ntop4 (src, dst, cnt));
>> -#endif
>>
>> #if HAVE_IPV6
>> case AF_INET6:
>
> This hunk would break portab
> > OK to apply? These are the last five references within gnulib where
> > we did not assume the existance of errno.
>
> Yes, please, for the patches that Bruno hasn't already applied.
> Thanks.
Done.
--
Eric Blake
Simon Josefsson wrote:
> @@ -78,10 +76,8 @@
> {
>switch (af)
> {
> -#if HAVE_IPV4
> case AF_INET:
>return (inet_ntop4 (src, dst, cnt));
> -#endif
>
> #if HAVE_IPV6
> case AF_INET6:
This hunk would break portability to systems without real networking,
such as Linux 0.
Mark D. Baushke wrote:
> FULL_PATH_INTTYPES_H = /usr/include/inttypes.h
> FULL_PATH_STDINT_H = /usr/include/stdint.h
>
> which means that stdint.h has this:
>
> ...other conditionals that probably do not lead to this block being
> ...used, even though it really should be included as this is where
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> On Sat, 2006-06-17 at 21:02 +0200, Simon Josefsson wrote:
>> Hi Yoann! Ok to install this? Gnulib assumes that sys/types.h
>> exists, and inet_ntop never tested HAVE_SYS_TYPES_H anyway.
>
> Hi Simon,
>
> Did you make sure that removing the sys/t
"James Youngman" <[EMAIL PROTECTED]> writes:
> I believe so. In findutils I ended up working around the problem by
> defining a FINDLIB_REPLACE_FUNCS defun which populates @[EMAIL PROTECTED]
> In other words I used essentially the same idea but with different
> macro and variable names.
Couldn'
[EMAIL PROTECTED] (Karl Berry) writes:
> I finally started switching to standard gnulib usage in Texinfo. I did
> gnulib-tool --import getopt gettext
> for starters, did the requisite configure.ac and Makefile.am stuff.
>
> But then, rerunning automake gave me complaints like this:
> gnulib/lib
On Sat, 2006-06-17 at 21:02 +0200, Simon Josefsson wrote:
> Hi Yoann! Ok to install this? Gnulib assumes that sys/types.h
> exists, and inet_ntop never tested HAVE_SYS_TYPES_H anyway.
Hi Simon,
Did you make sure that removing the sys/types.h requirement doesn't
break the build on some platform,
* Paul Eggert wrote on Mon, Jun 19, 2006 at 11:47:35AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > BTW, are the bugs wrt. as-needed fixed on all systems now?
>
> Sorry, I don't know. I don't know what the bugs were. Would they
> have affected coreutils?
I don't know. One referen
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> On Sat, 2006-06-17 at 20:48 +0200, Simon Josefsson wrote:
>> Hi Yoann! Ok to install this? The reason is that inet_ntop6 calls
>> inet_nto4, so it doesn't make sense to make IPv4 optional. The
>> current code wouldn't work on a platform that HA
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> I'd like to avoid that gnulib ends up just dumping all needed
> libraries into one variable, forcing gnulib users to bite and link
> against them all or use $as_needed (whatever it's called): the
> choice whether it's useful or not should clearly be pu
Thanks for reporting that. Wouldn't it be safer to skip all forms
of defining alloca, if it's already defined? I installed this,
which puts an "#ifndef alloca" around everything.
2006-06-19 Paul Eggert <[EMAIL PROTECTED]>
* alloca_.h (alloca) [defined alloca]: Don't define or declare.
On Sat, 2006-06-17 at 20:48 +0200, Simon Josefsson wrote:
> Hi Yoann! Ok to install this? The reason is that inet_ntop6 calls
> inet_nto4, so it doesn't make sense to make IPv4 optional. The
> current code wouldn't work on a platform that HAVE_IPV6 but not
> HAVE_IPV4, if there are any.
Hi Sim
On FreeBSD 6.1, the file /usr/include/stdlib.h has the following
on lines 219 through 233 inclusive:
/*
* The alloca() function can't be implemented in C, and on some
* platforms it can't be implemented at all as a callable function.
* The GNU C compiler provides a built-in alloca() which we ca
[EMAIL PROTECTED] (Eric Blake) writes:
> OK to apply? These are the last five references within gnulib where
> we did not assume the existance of errno.
Yes, please, for the patches that Bruno hasn't already applied.
Thanks.
The following works around the problem that the Makefile substituion of
the stdint_.h file generates illegal (missing quotes or angle brackets)
# include /usr/include/inttypes.h
or
# include /usr/include/stdint.h
for hosts that have one or the other of the or
files which need to be include
Simon Josefsson <[EMAIL PROTECTED]> writes:
> --- read-file.c 16 Jun 2006 21:26:36 +0200 1.1
> +++ read-file.c 17 Jun 2006 18:22:29 +0200
> @@ -43,6 +43,9 @@
>if (!buf)
> return NULL;
>
> + if (ferror (stream))
> +return NULL;
> +
>while (!feof (stream))
* Paul Eggert wrote on Mon, Jun 19, 2006 at 09:35:43AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > One problem with generally using this is that libtool will track the
> > library dependencies regardless of whether the library is actually
> > needed or not -- it cannot know.
>
> 'ca
[EMAIL PROTECTED] (Larry Jones) writes:
> Simon Josefsson writes:
>>
>> I believe the one in glibc does. Also, 1003.1-2004 says malloc should
>> set errno:
>
> But the C Standard doesn't. All the world isn't POSIX.
Yes, but it doesn't hurt to report the same errno that malloc
reported. If mal
Bruno Haible <[EMAIL PROTECTED]> writes:
> linktool gcc -o cp cp.o ../lib/libcoreutils.a $(LDADD)
>
> The idea would be that it removes -l options from the command line as long
> as the link continues to succeed. 'vim' links this way.
It would be nice to have something portable, but the naiv
Albert Chin <[EMAIL PROTECTED]> writes:
> --as-needed.
Thanks for mentioning that. I assumed that since binutils "ld -z
ignore" worked, that it paid attention to the "-z ignore" option. It
doesn't; it ignores it (:-). I just now verified this by inspecting
the source code; there is undocumente
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I think you are overlooking the changes in Technical Corrigendum 1
Yes, as I understand it the intent is that on a typical host with
16-bit short int and 32-bit int, this implementation is correct:
#define INT16_C(v) v
#define UINT16_C(v) v
Note that UINT
30 matches
Mail list logo
