[GRASS-dev] compilation issues with lex

[Markus Neteler]

On Thu, Aug 17, 2006 at 01:05:28PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > I have started to compile the well known software on
> > > > the new geodata blade of OSGeo nad encountered a few
> > > > problems:
> > > > 
> > > > cd lib/db/sqlp
> > > > make
> > > > gcc -I/mnt/home/neteler/software/grass6_cvs/dist.i686-pc-linux-gnu/include  -g -Wall -pedantic -Werror-implicit-function-declaration -fno-common    -fPIC    -DPACKAGE=\""grasslibs"\"     -DPACKAGE=\""grasslibs"\"  -I/mnt/home/neteler/software/grass6_cvs/dist.i686-pc-linux-gnu/include \
> > > >         -o OBJ.i686-pc-linux-gnu/lex.yy.o -c lex.yy.c
> > > > lex.l: In function 'yylex':
> > > > lex.l:76: error: implicit declaration of function 'strdup'
> > > 
> > > > cd raster/r.mapcalc
> > > > [neteler at xblade11-2 r.mapcalc]$ make
> > > > gcc -I/mnt/home/neteler/software/grass6_cvs/dist.i686-pc-linux-gnu/include  -g -Wall -pedantic -Werror-implicit-function-declaration -fno-common        -DPACKAGE=\""grassmods"\"  -I/mnt/home/neteler/software/grass6_cvs/dist.i686-pc-linux-gnu/include \
> > > >         -o OBJ.i686-pc-linux-gnu/lex.yy.o -c lex.yy.c
> > > > mapcalc.l: In function 'yylex':
> > > > mapcalc.l:134: error: implicit declaration of function 'strdup'
> > > 
> > > strdup() is defined in <string.h>, but it isn't ANSI and you're using
> > > -pedantic.
> > 
> > The problem remains when I don't use -pedantic.
> > 
> > I assume that -Werror-implicit-function-declaration is the problem
> > now:
> > 
> > MYCFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common"
> > MYCXXFLAGS="-g -Wall"
> 
> It shouldn't be; with the default feature macros (i.e. _GNU_SOURCE),
> including <string.h> should declare strdup().
> 
> OTOH, I'm a bit confused by:
> 
> lex.l:76: warning: incompatible implicit declaration of built-in function 'strdup'
> 
> which suggests that strdup() is a built-in function. strdup() isn't a
> particularly obvious choice for a built-in function; most built-in
> functions tend to be something which can be implemented in a handful
> of CPU instructions, e.g. memset, memcpy, etc.
> 
> I suggest looking at the logic surrounding the declaration of strdup()
> in string.h, in case that provides any clues.

Here we are:

/usr/include/string.h:
#if defined __USE_SVID || defined __USE_BSD || defined __USE_XOPEN_EXTENDED
/* Duplicate S, returning an identical malloc'd string.  */
extern char *strdup (__const char *__s)
     __THROW __attribute_malloc__ __nonnull ((1));
#endif

rpm -qf /usr/include/string.h
glibc-headers-2.3.6-3

cat /etc/issue
Fedora Core release 4 (Stentz)
Kernel \r on an \m

uname -a
Linux xblade11-2 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:14 EDT 2006 i686 athlon i386 GNU/Linux

rpm -qf `which lex`
flex-2.5.4a-40.fc4



###########
On my RHEL4 office box I have
#if defined __USE_SVID || defined __USE_BSD || defined __USE_XOPEN_EXTENDED
/* Duplicate S, returning an identical malloc'd string.  */
extern char *strdup (__const char *__s)
     __THROW __attribute_malloc__ __nonnull ((1));
#endif

which looks identical to me (there no problem).

###########

Anything else I should look for?

thanks
 Markus