Thread: [Aide-devel] Flex dependency, help needed
Brought to you by:
hvhaugwitz,
rvdb
From: Richard v. d. B. <ri...@vd...> - 2003-10-28 19:01:57
|
I just made my first attempt to package aide release 0.10. Compiling on Solaris (flex 2.5.4) went fine. While testing on Linux with flex 2.5.31 I got: flex -Pconf -oconf_lex.c /home/richard/tmp/aide/sf/aide-0.10/src/conf_lex.l gcc -DHAVE_CONFIG_H -I. -I/home/richard/tmp/aide/sf/aide-0.10/src -I.. -I/usr/local/include -I/home/richard/tmp/aide/sf/aide-0.10/include -I/home/richard/tmp/aide/sf/aide-0.10 -I/home/richard/tmp/aide/sf/aide-0.10/src -static -g -O2 -static -c conf_lex.c /home/richard/tmp/aide/sf/aide-0.10/src/conf_lex.l: In function `conf_put_token': /home/richard/tmp/aide/sf/aide-0.10/src/conf_lex.l:385: error: `yytext_ptr' undeclared (first use in this function) /home/richard/tmp/aide/sf/aide-0.10/src/conf_lex.l:385: error: (Each undeclared identifier is reported only once /home/richard/tmp/aide/sf/aide-0.10/src/conf_lex.l:385: error: for each function it appears in.) make[2]: *** [conf_lex.o] Error 1 make[2]: Leaving directory `/home/richard/tmp/aide/sf/aide-0.10/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/richard/tmp/aide/sf/aide-0.10' make: *** [all-recursive-am] Error 2 It looks like it has to do with this line in conf_lex.c: unput(s[i]); which is defined as: #define unput(c) yyunput( c, (yytext_ptr) ) I think yytext_ptr is probably undefined too soon. Anyway, downgrading flex to 2.5.4 solved the problem, because yytext_ptr is never #undef-ed. This is now a compile time dependency on flex 2.5.4a or older. Is this at all acceptable? Is there anyone here that knows how to fix conf_lex.l to make it flex 2.5.31 compatible? If anyone wants to give the aide_0.10.tar.gz file a try, let me know and I'll send it to you. Cheers, Richard |
From: Mike M. <mi...@ma...> - 2003-10-29 05:28:28
|
The following line might help: %option noyywrap But, I can't test that right now, due to my build environment being a bit wonky. I'm wondering if it might be in our interests to put out a request for part-time involvement from someone who knows lex. I sure don't. :) Does the autoconf stuff look useful for release? I'm still working on getting it 2.5-ized (it's a royal pain), but I'd like to at least use up-to-date config.sub/guess files for the 0.10 release. I can try doing so tonight, if you'd like. -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Mike M. <mi...@ma...> - 2003-10-29 06:40:50
|
On Tue, Oct 28, 2003 at 09:28:10PM -0800, Mike Markley <mi...@ma...> wrote: > Does the autoconf stuff look useful for release? I'm still working on > getting it 2.5-ized (it's a royal pain), but I'd like to at least use > up-to-date config.sub/guess files for the 0.10 release. I can try doing > so tonight, if you'd like. Er, right, that's not in CVS, so that should be fine once you generate the package ;). -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Richard v. d. B. <ri...@vd...> - 2003-10-29 10:09:12
|
Mike Markley wrote: >>Does the autoconf stuff look useful for release? I'm still working on >>getting it 2.5-ized (it's a royal pain), but I'd like to at least use >>up-to-date config.sub/guess files for the 0.10 release. I can try doing >>so tonight, if you'd like. > > Er, right, that's not in CVS, so that should be fine once you generate > the package ;). This confused me as well: $ sh autogen.sh Running aclocal... Running autoheader... Running automake --gnu ... automake: configure.in: required file `./config.guess' not found automake: configure.in: required file `./config.sub' not found Running autoconf... You can now run "./configure" and then "make". But since it seems that generate configure works fine, I figured it was not a problem for the 0.10 release. Am I right? I really should learn more about this autoconf/automake stuff. :-) Richard |
From: Mike M. <mi...@ma...> - 2003-10-29 11:06:26
|
On Wed, Oct 29, 2003 at 11:09:05AM +0100, Richard van den Berg <ri...@vd...> wrote: > automake: configure.in: required file `./config.guess' not found > automake: configure.in: required file `./config.sub' not found libtoolize --force --copy will grab those files. Before you use them, though, let me know what the date in each is :). -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Richard v. d. B. <ri...@vd...> - 2003-10-29 11:25:57
|
Mike Markley wrote: >>automake: configure.in: required file `./config.guess' not found >>automake: configure.in: required file `./config.sub' not found > > libtoolize --force --copy will grab those files. Before you use them, > though, let me know what the date in each is :). That works, but not really. Running libtoolize is no problem, but after that using autogen.sh produces funky errors. I'm not going to mess with this until I understand what is going on. Do we really need libtool for aide? As you requested: config.sub: timestamp='2003-07-17' config.guess: timestamp='2003-07-02' Richard |
From: Richard v. d. B. <ri...@vd...> - 2003-10-29 09:56:31
|
Mike Markley wrote: > The following line might help: > %option noyywrap I can't get this to work. The idea is that you can no longer use unput() after the %% block. Instead you can put the function inside the %% block between %{ and %}. However, when I do that (with or without %option noyywrap) I get in conf_lex.c: YY_DECL { [snip] void conf_put_token(const char* s){ Somehow the YY_DECL block means that conf_put_token is not defined in a global scope, so linking fails: /home/richard/tmp/aide/sf/aide-0.10/src/commandconf.c:495: undefined reference to `conf_put_token' Richard |
From: Mike M. <mi...@ma...> - 2003-10-29 06:53:30
|
Oh, even better, there's now a -l flag to flex that uses the old behavior. I fixed up my build system and I can actually compile the file flex -l produces... -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Richard v. d. B. <ri...@vd...> - 2003-10-29 10:29:43
|
Mike Markley wrote: > Oh, even better, there's now a -l flag to flex that uses the old > behavior. I fixed up my build system and I can actually compile the > file flex -l produces... Good one! I added this flag to the Makefile.am and all seems fine. The issue was with flex, not really our .l file. It seems flex is no longer POSIX compliant. Thanks Mike! Richard |
From: Mike M. <mi...@ma...> - 2003-10-29 11:06:58
|
On Wed, Oct 29, 2003 at 11:29:36AM +0100, Richard van den Berg <ri...@vd...> wrote: > Good one! I added this flag to the Makefile.am and all seems fine. The > issue was with flex, not really our .l file. It seems flex is no longer > POSIX compliant. If I'm not mistaken, it's actually being really really uptight about C99. Annoying either way... -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Mike M. <mi...@ma...> - 2003-10-29 21:19:21
|
On Wed, Oct 29, 2003 at 12:25:50PM +0100, Richard van den Berg <ri...@vd...> wrote: > That works, but not really. Running libtoolize is no problem, but after > that using autogen.sh produces funky errors. I'm not going to mess with > this until I understand what is going on. Do we really need libtool for > aide? Umm... it may cause issues with building on weird platforms. With that said, I don't know how much of the non-shared-library related stuff uses those files' contents. > config.sub: timestamp='2003-07-17' > config.guess: timestamp='2003-07-02' Those are reasonably up-to-date... :) BTW, what's up with the mkrelease.sh script? Shouldn't we just use cvs export for that? P.S. No need to Cc: me on list replies... :) -- Mike Markley <mi...@ma...> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 |
From: Richard v. d. B. <ri...@vd...> - 2003-10-29 21:32:12
|
> BTW, what's up with the mkrelease.sh script? Shouldn't we just use cvs > export for that? As you can tell, I am not too familiar with cvs. I'll remove that script and use "cvs export" instead. :-) Richard |