[unixODBC-dev] Re: Compilation problem in 2.2.9

Drew Hussey drewh at jcpaper.com
Thu Jul 15 16:53:20 BST 2004


"Nick Gorham" <nick at easysoft.com> wrote in message
news:40F24A9C.9030202 at easysoft.com...
> Emmanuel Charpentier wrote:
> > Dear list,
> >
> > 2.2.9 seems to have a compilation problem in sqp. During make :
> >
> > source='lex.c' object='lex.lo' libtool=yes \
> > depfile='.deps/lex.Plo' tmpdepfile='.deps/lex.TPlo' \
> > depmode=gcc3 /bin/sh ../depcomp \
> > /bin/sh ../libtool --mode=compile gcc -DPACKAGE_NAME=\"\"
> > -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
> > -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\" -DVERSION=\"2.2.9\"
> > -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1
> > -DLTDL_SHLIB_EXT=\".so\" -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1
> > -DHAVE_READLINE_HISTORY_H=1 -DHAVE_READLINE=1 -DTIME_WITH_SYS_TIME=1
> > -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=4 -DHAVE_LONG_LONG=1
> > -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1
> > -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1
> > -DHAVE_LIBPTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1
> > -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1
> > -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1
> > -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1
> > -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DIRENT_H=1
> > -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_PUTENV=1
> > -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1
> > -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1  -I. -I. -I../include    -g -O2
> > -pthread -c -o lex.lo `test -f 'lex.c' || echo './'`lex.c
> > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\"
> > -DVERSION=\"2.2.9\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> > -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1 -DLTDL_SHLIB_EXT=\".so\"
> > -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1
> > -DHAVE_READLINE_HISTORY_H=1 -DHAVE_READLINE=1 -DTIME_WITH_SYS_TIME=1
> > -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=4 -DHAVE_LONG_LONG=1
> > -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1
> > -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1
> > -DHAVE_LIBPTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1
> > -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1
> > -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1
> > -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1
> > -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1
> > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DIRENT_H=1
> > -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_PUTENV=1
> > -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1
> > -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -I. -I. -I../include -g -O2 -pthread
> > -c lex.c -MT lex.lo -MD -MP -MF .deps/lex.TPlo  -fPIC -DPIC -o lex.lo
> > lex.l: In function `yyerror':
> > lex.l:241: error: `YY_FLUSH_BUFFER' undeclared (first use in this
function)
> > lex.l:241: error: (Each undeclared identifier is reported only once
> > lex.l:241: error: for each function it appears in.)
> > make[1]: *** [lex.lo] Erreur 1
> > make[1]: quittant le répertoire «
> > /home/charpent/unixODBC/unixODBC-2.2.9/sqp »
> > make: *** [all-recursive] Erreur 1
> > charpent at yod:~/unixODBC/unixODBC-2.2.9$
> >
> > Wrong lex|bison ? If so which one should I use ? If not, isn't it a bug
?
> >
> >                     Emmanuel Charpentier
>
> I have seen this on one platform, can you try deleting the lex.c from
> the sqp directory and trying again ?
>
> What platform is this on, I will check here.
>
> -- 
> Nick


I am experiencing the exact same problem. I am using Crux 2.0 with

bison 1.875
flex 2.531
gcc 3.3.3
and qt 3.3.2

moving lex.c to another filename produced the same error still.


Thanks,

Drew Hussey





More information about the unixODBC-dev mailing list