Paul Eggert <[EMAIL PROTECTED]> writes:
> But do you really need float.h? See below.
>
>> +static inline int gl_isfinitef (float x)
>> +{
>> + return x >= -FLT_MAX && x <= FLT_MAX;
>> +}
>
> How about 'return x - x == 0;' instead? That's easier to configure;
> you don't need to worry about .
C
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues wrote:
>> On Tru64 4.0D, /usr/include.dtk/math.h declares round, roundf and
>> roundl, but I can't find a library that defines them. Same thing for
>> roundf and roundl and respective tests.
>>
>> This causes link failures for the test-r
Sam Steingold wrote:
> > But it's better to use canonicalize_file_name()
>
> it comes with a huge dependecy set...
There is an alternative modules 'canonicalize-lgpl'; it has fewer dependencies.
Bruno
Ralf Wildenhues wrote:
> 2007-10-22 Ralf Wildenhues <[EMAIL PROTECTED]>
>
> * lib/realloc.c [defined malloc]: Undefine, for prototype
> on Tru64 4.0D. Also define NEED_REALLOC_GNU.
>
> diff --git a/lib/realloc.c b/lib/realloc.c
> index 18cc628..190e554 100644
> --- a/lib/realloc.c
> * Bruno Haible <[EMAIL PROTECTED]> [2007-10-27 00:25:01 +0200]:
>
> Sam Steingold wrote:
>> CLISP comes with a replacement realpath implementation for platforms
>> which lacks it (are there still such platforms?).
>
> If someone provides a correct implementation of realpath for gnulib,
> we will
Ralf Wildenhues wrote:
> Well, it comes from the age-old interface of AC_FUNC_MALLOC (upon which
> lots of non-gnulib code relies, BTW).
>
> Are you suggesting that gnulib not use AC_FUNC_MALLOC, but use a copy of
> its own that does not #define malloc to rpl_malloc?
You're right, it's better not
Hello Ralf,
Thanks for explaining how this can work. I didn't know that
"config.status --file=..." was applicable also to files that are not
mentioned by AC_CONFIG_FILES.
Ralf Wildenhues wrote:
> you'd go to:
>
> # We need the following in order to create when the system
> # doesn't have on
Eric Blake wrote:
> the gnulib policy is that must be included first in all .c
> files, and never in gnulib's .h files. If you consistently follow this
> rule in your projects, then you won't run into problems with inconsistent
> parsing of gnulib .h files.
Yes. Thanks for saying it so clearly:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to iobrain ... on 10/27/2007 11:55 AM:
> I answer myself. I missed include config.h at begining of file. However,
> I think it could add at begining of gl_list.h, of the same way gl_list.c do!
> Thanks anyway and excuse me.
No, the gnulib po
Hello Bruno,
* Bruno Haible wrote on Mon, Oct 15, 2007 at 09:19:01PM CEST:
> Sam Steingold wrote:
> > gnulib/gnulib/m4/stdint offers a multi-line sed rule for generating
> > stdint.h from stdint_.h,
> > why do I need to maintain the sed command by hand?
> > why can't this be done by config.status
Hello Bruno,
Sorry for the delay.
* Bruno Haible wrote on Tue, Oct 23, 2007 at 01:08:54AM CEST:
> Ralf Wildenhues wrote:
> > on Tru64 4.0D I got this:
> >
> > | cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\"
> > -I. -I.. -I../../dummy-0/gllib -I../intl -ieee -g -c -
I answer myself. I missed include config.h at begining of file. However, I
think it could add at begining of gl_list.h, of the same way gl_list.c do!
Thanks anyway and excuse me.
2007/10/27, iobrain ... <[EMAIL PROTECTED]>:
>
> Greetings!
>
> I have several troubles linking my program with libgnu.
Alle sabato 27 ottobre 2007, Sylvain Beucler ha scritto:
> Hello Timothy,
> (bug-gnulib: FYI - maybe clarify the canonical gnulib source location)
>
> I noticed 2 issues in your Gnulib Gentoo package:
>
> - The package is built from the CVS sources. Please note that
> development moved to Git, so
Greetings!
I have several troubles linking my program with libgnu.a. It works nice on
some functions
but It always fails with list modules functions (as `gl_list_create'). I
have made sure that
Makefile links correctly. I cannot found good documentation about how to
should I build it,
so I don't
> - The package uses a wrapper in /usr/bin/gnulib-tool to
> /usr/share/gnulib/gnulib-tool.
Such a wrapper is actually unnecessary: gnulib-tool determines its own
location by itself (search for 'self_abspathname'). Therefore a symbolic
link from /usr/bin/gnulib-tool to /usr/share/gnulib/gnulib-to
Hello Timothy,
(bug-gnulib: FYI - maybe clarify the canonical gnulib source location)
I noticed 2 issues in your Gnulib Gentoo package:
- The package is built from the CVS sources. Please note that
development moved to Git, so the CVS sources are now outdated.
Check: http://git.savannah.gnu.
16 matches
Mail list logo
