On 3/28/06, James Antill <[EMAIL PROTECTED]> wrote:
> "Axel Liljencrantz" <[EMAIL PROTECTED]> writes:
>
> > Oh, prototypes for fallback functions are a hassle. I just don't know
> > what to do with them, honestly.
> >
> > On on hand, supplying prototypes for functions that are defined in
> > libc sometimes breaks things, like in this case where it would seem
> > the prototype in NetBSD libc is incompatible with the one fish has.
> >
> > On the other hand, sometimes libc provides a function but no
> > prototype. This is true for instance with glibc and the *wprintf
> > functions. In order to get these function prototypes, you need to
> > supply the --std=c99 switch to the compiler, but even if you don't,
> > the actual functions are there. In order to get prototypes for some
> > additional wcs* functions, you also need to supply additional
> > #defines.
> >
> > If somebody has input on how this could be handled without breaking on
> > any platforms, and without adding gcc-specific switches, please speak
> > up.
>
> You _really_ don't want to be defining prototypes like that, esp. as
> that's likely to break when -std=gnu99 becomes the default.
> Two ways to work around this are:
You're right. It was a mistake on my part thinking that it couldn't hurt.
>
> . try adding -std=gnu99 and/or -std=c99 to the CFLAGS in autoconf, if
> it fails don't use it (and assume nothing is prototyped/available).
>
There are numerous actual tests of what functionality is available,
the above method would ignore those and assume that any non-gcc
compiler compes from the stoneage. I've implemented something similar,
though. This configure.ac snippet (must be used after AC_PROG_CC)
tests if CC is gcc and if so, set a few switches that should improve
the odds of things going right on gcc systems.
#
# If we are using gcc, set some flags that increase the odds of the
# compiler producing a working binary...
#
if test "$CC" = gcc; then
#
# This seems to be needed in some glibc versions in order to get
# the prototypes for wide character functions like wcsdup and
# fwprintf. Fish should not actually use anu C99-specific
# features - if it does, please report this as a bug.
#
CFLAGS="$CFLAGS -std=c99"
...
fi
It should set the CFLAGS needed to build fish using gcc, and as an
added advantage, gcc-specific CFLAGS are only added if we are indeed
compiling using gcc. This means fish should build with any modern C
compiler, which is nice. (Probably doesn't, bound to be a few GNU:ism
in there somewhere)
> . Add:
>
> #define _ISOC99_SOURCE 1
>
> ...somewhere in your headers (see /usr/include/features.h or
> info libc).
This is an interesting alternative. Fish doesn't actually use any C99
language features that I know of, but it does use wprintf, which is
defined in C99. Would it be more correct to define _ISOC99_SOURCE?
This method should hopefully have the advantage that a C99-conformant
non-gcc compiler using glibc will work without intervention. Is there
any reason not to do both?
>
> --
> James Antill -- [EMAIL PROTECTED]
> http://www.and.org/and-httpd
>
--
Axel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
