A slight compile problem.
Forum rules
NOTICE: This forum is archived as read only.
Please use the Github Discussions at https://github.com/exult/exult/discussions
NOTICE: This forum is archived as read only.
Please use the Github Discussions at https://github.com/exult/exult/discussions
A slight compile problem.
Hello, I downloaded the source for the 11th of May.
Here is an error encountered after typing make.
==========================================================================
make[2]: Entering directory `/usr/ports/game/exult/exult/usecode'
Making all in compiler
make[3]: Entering directory `/usr/ports/game/exult/exult/usecode/compiler'
bison -y -d `test -f 'ucparse.yy' || echo './'`ucparse.yy
sed '/^#/ s|y\.tab\.c|ucparse.cc|' y.tab.c >ucparse.cc
rm -f y.tab.c
if test -f y.tab.h; then \
to=`echo "ucparse_H" | sed \
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
-e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`; \
sed "/^#/ s/Y_TAB_H/$to/g" y.tab.h >ucparse.ht; \
rm -f y.tab.h; \
if cmp -s ucparse.ht ucparse.h; then \
rm -f ucparse.ht ;\
else \
mv ucparse.ht ucparse.h; \
fi; \
fi
if test -f y.output; then \
mv y.output ucparse.output; \
fi
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I./../../headers -I./.. -I./../../files -I./../.. -O2 -Wno-long-long -g -O2 -MT ucparse.o -MD -MP -MF ".deps/ucparse.Tpo" \
-c -o ucparse.o `test -f 'ucparse.cc' || echo './'`ucparse.cc; \
then mv ".deps/ucparse.Tpo" ".deps/ucparse.Po"; \
else rm -f ".deps/ucparse.Tpo"; exit 1; \
fi
ucparse.cc: In function `int yyparse()':
ucparse.cc parse error before `goto'
make[3]: *** [ucparse.o] Error 1
make[3]: Leaving directory `/usr/ports/game/exult/exult/usecode/compiler'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/ports/game/exult/exult/usecode'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/ports/game/exult/exult'
make: *** [all] Error 2
==========================================================================
Some info that might help.
I have:
* glibc 2.3.2
* gcc 3.2.2
* sdl 1.2.5
* sdl mixer 1.2.5
Thanks for any help.
Here is an error encountered after typing make.
==========================================================================
make[2]: Entering directory `/usr/ports/game/exult/exult/usecode'
Making all in compiler
make[3]: Entering directory `/usr/ports/game/exult/exult/usecode/compiler'
bison -y -d `test -f 'ucparse.yy' || echo './'`ucparse.yy
sed '/^#/ s|y\.tab\.c|ucparse.cc|' y.tab.c >ucparse.cc
rm -f y.tab.c
if test -f y.tab.h; then \
to=`echo "ucparse_H" | sed \
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
-e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`; \
sed "/^#/ s/Y_TAB_H/$to/g" y.tab.h >ucparse.ht; \
rm -f y.tab.h; \
if cmp -s ucparse.ht ucparse.h; then \
rm -f ucparse.ht ;\
else \
mv ucparse.ht ucparse.h; \
fi; \
fi
if test -f y.output; then \
mv y.output ucparse.output; \
fi
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I./../../headers -I./.. -I./../../files -I./../.. -O2 -Wno-long-long -g -O2 -MT ucparse.o -MD -MP -MF ".deps/ucparse.Tpo" \
-c -o ucparse.o `test -f 'ucparse.cc' || echo './'`ucparse.cc; \
then mv ".deps/ucparse.Tpo" ".deps/ucparse.Po"; \
else rm -f ".deps/ucparse.Tpo"; exit 1; \
fi
ucparse.cc: In function `int yyparse()':
ucparse.cc parse error before `goto'
make[3]: *** [ucparse.o] Error 1
make[3]: Leaving directory `/usr/ports/game/exult/exult/usecode/compiler'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/ports/game/exult/exult/usecode'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/ports/game/exult/exult'
make: *** [all] Error 2
==========================================================================
Some info that might help.
I have:
* glibc 2.3.2
* gcc 3.2.2
* sdl 1.2.5
* sdl mixer 1.2.5
Thanks for any help.
Re: A slight compile problem.
which version of flex and bison are you using?
Re: A slight compile problem.
Btw, the code in the usecode/compiler directory hasn't changed in quite a while.
Re: A slight compile problem.
I've got the same version of flex, but not of bison. Try downgrading to an
older bison version (I use 1.35, I don't know what the others use). IIRC,
some of the newer bison versions have idosyncracies and different
defaults to the older ones, which is what you might be tripping up on.
Exult+tools compiled fine for me with the 1.35 version, I'll upgrade to a
later one I've got installed, to see if that breaks the compile sometime
today if I get the chance.
older bison version (I use 1.35, I don't know what the others use). IIRC,
some of the newer bison versions have idosyncracies and different
defaults to the older ones, which is what you might be tripping up on.
Exult+tools compiled fine for me with the 1.35 version, I'll upgrade to a
later one I've got installed, to see if that breaks the compile sometime
today if I get the chance.
Re: A slight compile problem.
okay thanks for the speedy reply, I'll try out bison 1.35 later.
Re: A slight compile problem.
bison 1.35 and 1.75 work, but bison 1.875 dies in a rather spectacular manner as you've noticed. *grin*
Looks like a bug in bison to me, it's overreacting a bit to remove gcc's warnings.
Basicly what you want to do is to go to about line 2735 of exult/usecode/compiler/ucparse.cc,
just above from where the error is, and replace code that looks like:
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
__attribute__ ((__unused__))
#endif
... with the slightly modified (just added a // comment to the start of the middle line) code:
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
// __attribute__ ((__unused__))
#endif
Then run make again, and everything should work ok from there in. You
don't need to downgrade your bison for this, but you might want to
downgrade to bison 1.75, since it's apparently a little less buggy then the
latest release. *grin*
Darke
Looks like a bug in bison to me, it's overreacting a bit to remove gcc's warnings.
Basicly what you want to do is to go to about line 2735 of exult/usecode/compiler/ucparse.cc,
just above from where the error is, and replace code that looks like:
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
__attribute__ ((__unused__))
#endif
... with the slightly modified (just added a // comment to the start of the middle line) code:
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
// __attribute__ ((__unused__))
#endif
Then run make again, and everything should work ok from there in. You
don't need to downgrade your bison for this, but you might want to
downgrade to bison 1.75, since it's apparently a little less buggy then the
latest release. *grin*
Darke
Re: A slight compile problem.
again with the *grin*'s darke
thanks for the fix, is that now going to be added to CVS?
thanks for the fix, is that now going to be added to CVS?
Re: A slight compile problem.
AFAIK, it can't be, it's a modification on a postprocessed file. I'll see if I can
grab the bison cvs to see if it's still producing the same code, and
generating the same error, then cut down a testcase and submit it to
them as a bug if it is.
Unfortunately there's really nothing I know of that we can do, other then
to commit an already created ucparse.cc into cvs. Given the fact that I
know of no distros that are insane enough to include cutting edge
bison/flex into their distro, (most are still around 1.35 from what I've seen)
I suspect out best option is to fail at configure if --enable-compiler is used
and bison greater then 1.70 is detected. -.-
I am, of course, discounting the fact it *might* be a bug in the ucparse.yy
code, which admittedly is unlikely given it compiles perfectly with bison
1.35, 1.50, and 1.70.
Your best idea is probably (unless you *really* need the features,
whatever they are, bison 1.875 offers) to revert back to an older version
of bison, because you'll likely trip over other, similar oddness in programs
other then exult too.
Darke
(Reverting his system back to plain, old bison 1.35 after having half a
dozen versions installed on his system just then. *grin*)
grab the bison cvs to see if it's still producing the same code, and
generating the same error, then cut down a testcase and submit it to
them as a bug if it is.
Unfortunately there's really nothing I know of that we can do, other then
to commit an already created ucparse.cc into cvs. Given the fact that I
know of no distros that are insane enough to include cutting edge
bison/flex into their distro, (most are still around 1.35 from what I've seen)
I suspect out best option is to fail at configure if --enable-compiler is used
and bison greater then 1.70 is detected. -.-
I am, of course, discounting the fact it *might* be a bug in the ucparse.yy
code, which admittedly is unlikely given it compiles perfectly with bison
1.35, 1.50, and 1.70.
Your best idea is probably (unless you *really* need the features,
whatever they are, bison 1.875 offers) to revert back to an older version
of bison, because you'll likely trip over other, similar oddness in programs
other then exult too.
Darke
(Reverting his system back to plain, old bison 1.35 after having half a
dozen versions installed on his system just then. *grin*)
Re: A slight compile problem.
I'm getting a similar problem.
make[3]: Entering directory `/home/paul/exult/usecode/compiler'
/bin/sh ../../libtool --mode=link g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
ucparse.o(.text+0x65a): In function `yyparse()':
/home/paul/exult/usecode/compiler/ucparse.cc undefined reference to `yylex()'
ucparse.o(.text+0x2c45):/home/paul/exult/usecode/compiler/ucparse.cc undefined reference to `yylex()'
ucmain.o(.text+0xa1): In function `main':
/home/paul/exult/usecode/compiler/ucmain.cc:98: undefined reference to `yyin'
ucmain.o(.text+0x293):/home/paul/exult/usecode/compiler/ucmain.cc:84: undefined reference to `yyin'
collect2: ld returned 1 exit status
make[3]: *** [ucc] Error 1
Using Flex 2.5.4a and Bison 1.35, on Mandrake 9.1
make[3]: Entering directory `/home/paul/exult/usecode/compiler'
/bin/sh ../../libtool --mode=link g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
ucparse.o(.text+0x65a): In function `yyparse()':
/home/paul/exult/usecode/compiler/ucparse.cc undefined reference to `yylex()'
ucparse.o(.text+0x2c45):/home/paul/exult/usecode/compiler/ucparse.cc undefined reference to `yylex()'
ucmain.o(.text+0xa1): In function `main':
/home/paul/exult/usecode/compiler/ucmain.cc:98: undefined reference to `yyin'
ucmain.o(.text+0x293):/home/paul/exult/usecode/compiler/ucmain.cc:84: undefined reference to `yyin'
collect2: ld returned 1 exit status
make[3]: *** [ucc] Error 1
Using Flex 2.5.4a and Bison 1.35, on Mandrake 9.1
Re: A slight compile problem.
I ran that command manually:
darke@darke: ~/code/exult/usecode/compiler
> g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
darke@darke: ~/code/exult/usecode/compiler
>
... and it seems to work fine. Have you done a `make clean && make` recently?
If that doesn't work, can you do a `make clean && make` in the usecode/compiler directory and post the entire build log here? (It's relatively short, about 50 lines long on my system.
Darke
darke@darke: ~/code/exult/usecode/compiler
> g++ -g -O2 -o ucc ucparse.o uclex.o ucmain.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o
darke@darke: ~/code/exult/usecode/compiler
>
... and it seems to work fine. Have you done a `make clean && make` recently?
If that doesn't work, can you do a `make clean && make` in the usecode/compiler directory and post the entire build log here? (It's relatively short, about 50 lines long on my system.
Darke
Re: A slight compile problem.
'make clean && make' didn't work, but that gave me the idea to delete the directory and unzip the source again, and after that it compiled fine. Thanks for the help.