[GRASS-dev] compilation issues with lex

GRASS GIS GRASS GIS developer
1

Hi,

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'
lex.l:76: warning: incompatible implicit declaration of built-in function 'strdup'
lex.l:99: warning: incompatible implicit declaration of built-in function 'strdup'
lex.l:108: warning: incompatible implicit declaration of built-in function 'strdup'
lex.l:117: warning: incompatible implicit declaration of built-in function 'strdup'
lex.l:156: warning: incompatible implicit declaration of built-in function 'strdup'
lex.l: In function 'yyerror':
lex.l:246: error: implicit declaration of function 'snprintf'
lex.l:246: warning: incompatible implicit declaration of built-in function 'snprintf'
make: *** [OBJ.i686-pc-linux-gnu/lex.yy.o] Error 1

[neteler@xblade11-2 sqlp]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

Subsequently the DB drivers won't compile.

Same thing in r.mapcalc:

cd raster/r.mapcalc
[neteler@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'
mapcalc.l:134: warning: incompatible implicit declaration of built-in function 'strdup'
mapcalc.l:140: warning: incompatible implicit declaration of built-in function 'strdup'
make: *** [OBJ.i686-pc-linux-gnu/lex.yy.o] Error 1

Help appreciated since I am not familiar with lex.

thanks,

Markus

2

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@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.

GRASS relies upon various POSIX functions; if you use -ansi or
-pedantic, you also need -D_POSIX_SOURCE (you may require some others,
e.g. _SVID_SOURCE and/or _BSD_SOURCE; ideally, those two shouldn't be
necessary, but we can't do without _POSIX_SOURCE).

For r.mapcalc, we could get around this specific issue by using
G_store() instead. lib/db/sqlp doesn't currently use libgis, so using
G_store() would add a new dependency.

However, there may be other non-ANSI functions which are similarly
affected. When -ansi or -pedantic are used, ANSI headers such as
<string.h> don't declare any non-ANSI functions unless specifically
enabled using the appropriate macro from <features.h>.

Help appreciated since I am not familiar with lex.

This isn't specifically a lex issue; the use of strdup() is in C code
which lex copies verbatim to the output file (lex.yy.c).

--
Glynn Clements <glynn@gclements.plus.com>

3

On Thu, Aug 17, 2006 at 02:31:51AM +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@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"

r GRASS relies upon various POSIX functions; if you use -ansi or
-pedantic, you also need -D_POSIX_SOURCE (you may require some others,
e.g. _SVID_SOURCE and/or _BSD_SOURCE; ideally, those two shouldn't be
necessary, but we can't do without _POSIX_SOURCE).

OK - interestingly these flags work well on RHEL4 and Mandriva2006
(I am using them for 1-2 years now). Maybe it only depends on
the version of gcc.

For r.mapcalc, we could get around this specific issue by using
G_store() instead. lib/db/sqlp doesn't currently use libgis, so using
G_store() would add a new dependency.

However, there may be other non-ANSI functions which are similarly
affected. When -ansi or -pedantic are used, ANSI headers such as
<string.h> don't declare any non-ANSI functions unless specifically
enabled using the appropriate macro from <features.h>.

> Help appreciated since I am not familiar with lex.

This isn't specifically a lex issue; the use of strdup() is in C code
which lex copies verbatim to the output file (lex.yy.c).

Of course, when I reduce to
MYCFLAGS="-g -Wall"

it compiles.

Markus

4

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@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.

--
Glynn Clements <glynn@gclements.plus.com>

5

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@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

6

Markus Neteler wrote:

> 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

That's essentially what's in mine. Check that there isn't a private gcc
verion in /usr/lib/gcc[-lib]/<arch>/<version>/include. If there isn't,
I have no idea why it's saying "implicit declaration".

It might be worth checking lex.yy.c, to ensure that the
"#include <string.h>" is getting copied there.

--
Glynn Clements <glynn@gclements.plus.com>

7

On Thu, Aug 17, 2006 at 02:09:04PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > 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

That's essentially what's in mine. Check that there isn't a private gcc
verion in /usr/lib/gcc[-lib]/<arch>/<version>/include.

Here is what I found:

[neteler@xblade11-2 ~]$ l /usr/lib/gc
gcc/ gcc-lib/ gcj/ gcj-4.0.0/ gcj-4.0.2/ gconv/ gcrt1.o

-> looks ok

[neteler@xblade11-2 ~]$ l /usr/lib/gcc/i386-redhat-linux/4.0.2/
adainclude/ libgcc_s.so libmudflap.a
adalib/ libgcjawt.so libmudflap.so
crtbegin.o libgcj.so libmudflapth.a
crtbeginS.o libgcj.spec libmudflapth.so
crtbeginT.o libgcov.a libobjc.a
crtend.o libgfortran.a libobjc.so
crtendS.o libgfortranbegin.a libstdc++.a
include/ libgfortran.so libstdc++.so
libgcc.a libgij.so libsupc++.a
libgcc_eh.a lib-gnu-java-awt-peer-gtk.so

-> looks ok

[neteler@xblade11-2 ~]$ l /usr/lib/gcc-lib/i386-redhat-linux/
2.96/ 3.2.3/ 3.3.4/

#######
[neteler@xblade11-2 ~]$ ls /usr/lib/gcc-lib/i386-redhat-linux/2.96/
crtbegin.o crtbeginS.o crtend.o crtendS.o libgcc.a libgcc_eh.a

[neteler@xblade11-2 ~]$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a
compat-libgcc-296-2.96-132.fc4

#######
[neteler@xblade11-2 ~]$ ls /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/
cc1 cpp0 crtbeginT.o f771 libg2c.a libgcc_eh.a libstdc++.so tradcpp0
cc1plus crtbegin.o crtend.o include/ libg2c.so libgcc_s.so libsupc++.a
collect2 crtbeginS.o crtendS.o libfrtbegin.a libgcc.a libstdc++.a specs

[neteler@xblade11-2 ~]$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/crtbegin.o
compat-gcc-32-3.2.3-47.fc4

#######
[neteler@xblade11-2 ~]$ ls /usr/lib/gcc-lib/i386-redhat-linux/3.3.4/
libstdc++.a libstdc++.so libsupc++.a

[neteler@xblade11-2 ~]$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/3.3.4/libstdc++.so
compat-gcc-32-c++-3.2.3-47.fc4

If there isn't,
I have no idea why it's saying "implicit declaration".

It might be worth checking lex.yy.c, to ensure that the
"#include <string.h>" is getting copied there.

[neteler@xblade11-2 sqlp]$ pwd
/home/neteler/software/grass6_cvs/lib/db/sqlp

[neteler@xblade11-2 sqlp]$ grep string lex.yy.c | grep inclu
#include <string.h>

The code piece in lex.yy.c is:

[...]
* This program is free software under the GNU General Public
* License (>=v2). Read the file COPYING that comes with GRASS
* for details.
*
*****************************************************************************/
/**************** C-CODE *****************/
#line 24 "lex.l"
#include <grass/sqlp.h>
#include "y.tab.h"
#include <string.h>

#undef YY_INPUT
#define YY_INPUT(b, r, ms) (r = my_yyinput(b, ms))
[...]

Thanks for your patience. Maybe it's a gcc mystery.

Markus

8

Markus Neteler wrote:

> That's essentially what's in mine. Check that there isn't a private gcc
> verion in /usr/lib/gcc[-lib]/<arch>/<version>/include.

Here is what I found:

[neteler@xblade11-2 ~]$ l /usr/lib/gc
gcc/ gcc-lib/ gcj/ gcj-4.0.0/ gcj-4.0.2/ gconv/ gcrt1.o

-> looks ok

[neteler@xblade11-2 ~]$ l /usr/lib/gcc/i386-redhat-linux/4.0.2/
adainclude/ libgcc_s.so libmudflap.a
adalib/ libgcjawt.so libmudflap.so
crtbegin.o libgcj.so libmudflapth.a
crtbeginS.o libgcj.spec libmudflapth.so
crtbeginT.o libgcov.a libobjc.a
crtend.o libgfortran.a libobjc.so
crtendS.o libgfortranbegin.a libstdc++.a
include/ libgfortran.so libstdc++.so
libgcc.a libgij.so libsupc++.a
libgcc_eh.a lib-gnu-java-awt-peer-gtk.so

-> looks ok

It's what's in the "include" directory that is relevant. gcc may
override some system headers by placing an alternate version in that
directory.

> It might be worth checking lex.yy.c, to ensure that the
> "#include <string.h>" is getting copied there.

[neteler@xblade11-2 sqlp]$ pwd
/home/neteler/software/grass6_cvs/lib/db/sqlp

[neteler@xblade11-2 sqlp]$ grep string lex.yy.c | grep inclu
#include <string.h>

The code piece in lex.yy.c is:

[...]
* This program is free software under the GNU General Public
* License (>=v2). Read the file COPYING that comes with GRASS
* for details.
*
*****************************************************************************/
/**************** C-CODE *****************/
#line 24 "lex.l"
#include <grass/sqlp.h>
#include "y.tab.h"
#include <string.h>

No problems there.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Thu, Aug 17, 2006 at 03:55:05PM +0100, Glynn Clements wrote:

Markus Neteler wrote:
> [neteler@xblade11-2 ~]$ l /usr/lib/gcc/i386-redhat-linux/4.0.2/
> adainclude/ libgcc_s.so libmudflap.a
> adalib/ libgcjawt.so libmudflap.so
> crtbegin.o libgcj.so libmudflapth.a
> crtbeginS.o libgcj.spec libmudflapth.so
> crtbeginT.o libgcov.a libobjc.a
> crtend.o libgfortran.a libobjc.so
> crtendS.o libgfortranbegin.a libstdc++.a
> include/ libgfortran.so libstdc++.so
> libgcc.a libgij.so libsupc++.a
> libgcc_eh.a lib-gnu-java-awt-peer-gtk.so
>
> -> looks ok

It's what's in the "include" directory that is relevant. gcc may
override some system headers by placing an alternate version in that
directory.

Is this the beast?

[neteler@xblade11-2 scripts]$ grep strdup /usr/lib/gcc/i386-redhat-linux/4.0.2/include/*
/usr/lib/gcc/i386-redhat-linux/4.0.2/include/mf-runtime.h:#pragma redefine_extname strdup __mfwrap_strdup

Markus

10

Markus Neteler wrote:

> > [neteler@xblade11-2 ~]$ l /usr/lib/gcc/i386-redhat-linux/4.0.2/
> > adainclude/ libgcc_s.so libmudflap.a
> > adalib/ libgcjawt.so libmudflap.so
> > crtbegin.o libgcj.so libmudflapth.a
> > crtbeginS.o libgcj.spec libmudflapth.so
> > crtbeginT.o libgcov.a libobjc.a
> > crtend.o libgfortran.a libobjc.so
> > crtendS.o libgfortranbegin.a libstdc++.a
> > include/ libgfortran.so libstdc++.so
> > libgcc.a libgij.so libsupc++.a
> > libgcc_eh.a lib-gnu-java-awt-peer-gtk.so
> >
> > -> looks ok
>
> It's what's in the "include" directory that is relevant. gcc may
> override some system headers by placing an alternate version in that
> directory.

Is this the beast?

[neteler@xblade11-2 scripts]$ grep strdup /usr/lib/gcc/i386-redhat-linux/4.0.2/include/*
/usr/lib/gcc/i386-redhat-linux/4.0.2/include/mf-runtime.h:#pragma redefine_extname strdup __mfwrap_strdup

That wasn't what I was actually thinking of, but it certainly looks
relevant. I would guess that it's causing the compiler to ignore the
strdup() declaration from <string.h> due to the name change, although
the compiler still uses the original name in the error message.

The one thing I'm still not entirely sure about is why the problem
only affects the lex.yy.c files; other files use strdup():

  grass=> select * from obj_imp where symbol = 'strdup' ;
                         object | symbol
  -----------------------------------------------------+--------
   general/g.parser/OBJ.i686-pc-linux-gnu/main.o | strdup
   lib/db/sqlp/OBJ.i686-pc-linux-gnu/sql.o | strdup
   lib/db/sqlp/OBJ.i686-pc-linux-gnu/lex.yy.o | strdup
   raster/r.mapcalc/OBJ.i686-pc-linux-gnu/lex.yy.o | strdup
   raster/r.mapcalc/OBJ.i686-pc-linux-gnu/expression.o | strdup
   vector/v.in.ogr/OBJ.i686-pc-linux-gnu/main.o | strdup
  (6 rows)

It may be related to the fact that lex.yy.c doesn't include the
headers until quite far down. My copies include various standard
headers (including <string.h>) of their own accord, right at the top
of the file, although that could vary between lex implementations.

--
Glynn Clements <glynn@gclements.plus.com>