aMule Forum
English => Compilation problems => Topic started by: OldFrog on December 03, 2005, 09:33:56 AM
-
I feel so frustrated, couldn't build my daily rpm !
flex -o Scanner.cpp Scanner.l; \
cp Scanner.h.in Scanner.h
flex: can't open Scanner.cpp
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/wx/include/gtk2-unicode-release-2.7 -I/usr/include/wx-2.7 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -D__WXGTK__ -pthread -I./libs -DUSE_EMBEDDED_CRYPTO -W -Wall -Wshadow -Wundef -O2 -MT libmuleappcore_a-Scanner.o -MD -MP -MF ".deps/libmuleappcore_a-Scanner.Tpo" -c -o libmuleappcore_a-Scanner.o `test -f 'Scanner.cpp' || echo './'`Scanner.cpp; \
then mv -f ".deps/libmuleappcore_a-Scanner.Tpo" ".deps/libmuleappcore_a-Scanner.Po"; else rm -f ".deps/libmuleappcore_a-Scanner.Tpo"; exit 1; fi
g++: ./Scanner.cpp: Aucun fichier ou répertoire de ce type
g++: no input files
make[4]: *** [libmuleappcore_a-Scanner.o] Erreur 1
-
confirming, also seems to appear on the suse-9..3-box:
...
make[2]: Entering directory `/usr/src/packages/BUILD/amule-cvs/src'
bison --debug -t -d -v -o Parser.cpp Parser.y
flex -o Scanner.cpp Scanner.l; \
cp Scanner.h.in Scanner.h
flex: can't open Scanner.cpp
...
as posted in http://forum.amule.org/thread.php?threadid=8270&boardid=66&sid=
-
See attachment.
-
My makefile is with the spaces. I don't have a Scanner.cpp in the src-dir.
tux@ubuntu:~/Desktop/amule-cvs/src$ ls | grep Scanner
Scanner.h.in
Scanner.l
-
This is building on Mandriva 2006 against wxGtk CVS (from yesterday) built from Gtk2 and with unicode enabled.
-
Did you try the patch at all?
Originally posted by wuischke
My makefile is with the spaces.
Mine has spaces, too, but it shouldn't - at least not for our versions of flex. Mine is flex-2.5.4a-297. This is what the patch does. It removes the spaces.
Originally posted by wuischke
I don't have a Scanner.cpp in the src-dir.
It is generated by flex from Scanner.l.
This:
flex -oScanner.cpp Scanner.lmeans:
Process Scanner.l and save the output as Scanner.cpp.
The error message is confusing because it sounds like Scanner.cpp were missing as an input file, but that's not correct. Scanner.l is the input file and Scanner.cpp is the output file. flex gets it wrong because it expects another syntax, i.e. without spaces, and generates a confusing error message.
Originally posted by OldFrog
This is building on Mandriva 2006 against wxGtk CVS (from yesterday) built from Gtk2 and with unicode enabled.
wx doesn't matter. This problem is not related to wx.
-
Mine has spaces, too, but it shouldn't
Sry, didn't read the patchfile properly, 'cause I'm used to have spaces in between.
Just noticed another thing:
/bin/sh: flex: command not found
The same with Bison, it didn't complain during ./configure, just during make.
And thanks for your patch.
(http://img500.imageshack.us/img500/4535/cvs200512039am.th.jpg) (http://img500.imageshack.us/my.php?image=cvs200512039am.jpg)
-
I see the following extra problems with the recent bison/flex change, even with the above patch applied:
1. It doesn't work with out-of-source builds, e.g. something like:
cd amule-cvs
mkdir build
cd build
../configure
makeError message:
+ make
make all-recursive
make[1]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build'
Making all in m4
make[2]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build/m4'
make[2]: Für das Ziel »all« ist nichts zu tun.
make[2]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build/m4'
Making all in docs
make[2]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build/docs'
Making all in man
make[3]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build/docs/man'
make[3]: Für das Ziel »all« ist nichts zu tun.
make[3]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build/docs/man'
make[3]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build/docs'
make[3]: Für das Ziel »all-am« ist nichts zu tun.
make[3]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build/docs'
make[2]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build/docs'
Making all in src
make[2]: Entering directory `/usr/src/packages/BUILD/amule-cvs/build/src'
bison --debug -t -d -v -o Parser.cpp Parser.y
bison: kann Datei »Parser.y« nicht öffnen: Datei oder Verzeichnis nicht gefunden
make[2]: *** [Parser.cpp] Fehler 1
make[2]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/usr/src/packages/BUILD/amule-cvs/build'
make: *** [all] Fehler 2
error: Bad exit status from /var/tmp/rpm-tmp.3805 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.3805 (%build)2. What about non-GNU systems with their own yacc/lex implementations? Will it work with them?
Maybe there is a more autotoolish way to do that which takes care of these things automatically.
-
Three more additions...
- The ./configure check for bison and flex doesn't seem to be clean. Maybe that's intended and the generated files will be shipped in the future and were only forgotten in today's tarball.
- Exactly the same problem with out-of-source builds is also in src/webserver/src/Makefile.am with php_parser.y and php_lexer.l, but it doesn't show up unless these files are modified because the generated ones are shipped in the tarball.
- The problem with out-of-source builds can be solved by either including the generated files in the tarball or by replacing "lex -foo -bar -o bla.c bla.l" with "lex -foo -bar -o bla.c $(srcdir)/bla.l" or both.
-
Actually the patch against Makefile.am was not enough, I had to do the same change in Makefile.in and got the brand new rpm built. Running in now.
Besides that, Gerd, your point is more general than that. Anyway, should we need the whole first steps in a CVS (autogen, automake, etc) to have the cutting edge cleanest code ?
Being an IT for a living on some Mainframe software for 18 years (So you understand the "old" part of my nick :P ), I can relativise what is important and what is not in a project, you know, and there are times were rules may be a bit transgressed
.
Having bison and flex settings absolutely "kosher" is not the most urgent thing, I guess.
-
Originally posted by OldFrog
Actually the patch against Makefile.am was not enough, I had to do the same change in Makefile.in and got the brand new rpm built. Running in now.
Never modify Makefile.in directly! These are generated files and your modifications will be lost. Regenerate them from Makefile.am by running ./autogen.sh. I thought this was clear...
Originally posted by OldFrog
Having bison and flex settings absolutely "kosher" is not the most urgent thing, I guess.
Sorry, it's true that I can be perfectionist sometimes, but this is not about perfection, it's a build failure.
Furthermore, I think the problem is already fixed in CVS. Kry said he fixed it immediately after committing it: http://forum.amule.org/thread.php?threadid=8273
-
Ahyeah I did.
Additionally, I have the generated files commited. I don't like that much, but... seems to create too much problems around. I keep the source lex and bison files on SVN, so they can be regenerated an any time, and will be auto-regenerated when changed.