From: <Fl...@t-...> - 2006-01-20 11:02:08
|
hey folks, I'm tryin' to set up a cross compiling environment with mingw32 together with flex/bison on a linux box. Unfortunately it doesn't work yet. Let me explain, what I achieved so far: I've installed successfully Mingw32, so I can call: "i586-mingw32msvc-gcc hello.c -o hello.exe" and it works (the file is executable on a Windows system, compiled with linux). On the other hand I can use flex, e.g.: "flex lexan.l" to get: lex.yy.c and compile this like: "cc -o lexan lex.yy.c lexantest.c -lfl". Then I get "lexan" as a executable programm for linux. This works fine as well. The problem is to combine those two steps like: "i586-mingw32msvc-gcc -o lexan.exe lex.yy.c lexantest.c". Then the following message appears: /tmp/ccksNSNQ.o:lex.yy.c:(.text+0x417): undefined reference to `_yywrap' /tmp/ccksNSNQ.o:lex.yy.c:(.text+0xd42): undefined reference to `_yywrap' collect2: ld returned 1 exit status As I once had this problem, somebody told me that I have to compile the flex-source-package with: --target=i586-mingw32msvc option. Well, I've tried this (you can have a look at the configure - Logfile output below), but I'm not sure if it worked properly. Because there appear lines saying: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu but no line telling the target system type. So I'm not sure, if the target platform was detected properly. In order that it didn't worked properly, can anybody please tell me the proper "configure call" ? (like: ./configure --target=i586-mingw32msvc). My goal is, to develop software on a linux box but for windows platforms. Is there something else I have to pay attention when I want to use mingw32 together with flex/bison. Any tips appreciated. Thank you.. R@lf configure log: ---------------- checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking whether NLS is requested... yes checking for GNU gettext in libc... yes checking for bison... bison -y checking for flex... no checking for lex... no checking for yywrap in -lfl... yes checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether ln -s works... yes checking for ranlib... ranlib checking for bison... /usr/bin/bison checking for help2man... help2man checking for gnum4... no checking for gm4... no checking for m4... /usr/bin/m4 checking for indent... indent checking for log in -lm... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for unistd.h... (cached) yes checking stdbool.h usability... yes checking stdbool.h presence... yes checking for stdbool.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking sys/params.h usability... no checking sys/params.h presence... no checking for sys/params.h... no checking cunistd usability... no checking cunistd presence... no checking for cunistd... no checking for size_t... yes checking whether __func__ is declared... yes configure: creating ./config.status config.status: creating flex.spec config.status: creating Makefile config.status: creating doc/Makefile config.status: creating examples/Makefile config.status: creating examples/fastwc/Makefile config.status: creating examples/manual/Makefile config.status: creating m4/Makefile config.status: creating po/Makefile.in config.status: creating tools/Makefile config.status: creating tests/Makefile config.status: creating tests/TEMPLATE/Makefile config.status: creating tests/test-array-nr/Makefile config.status: creating tests/test-array-r/Makefile config.status: creating tests/test-basic-nr/Makefile config.status: creating tests/test-basic-r/Makefile config.status: creating tests/test-bison-yylloc/Makefile config.status: creating tests/test-bison-yylval/Makefile config.status: creating tests/test-c-cpp-nr/Makefile config.status: creating tests/test-c-cpp-r/Makefile config.status: creating tests/test-header-nr/Makefile config.status: creating tests/test-header-r/Makefile config.status: creating tests/test-include-by-buffer/Makefile config.status: creating tests/test-include-by-push/Makefile config.status: creating tests/test-include-by-reentrant/Makefile config.status: creating tests/test-multiple-scanners-nr/Makefile config.status: creating tests/test-multiple-scanners-r/Makefile config.status: creating tests/test-noansi-nr/Makefile config.status: creating tests/test-noansi-r/Makefile config.status: creating tests/test-prefix-nr/Makefile config.status: creating tests/test-prefix-r/Makefile config.status: creating tests/test-pthread/Makefile config.status: creating tests/test-string-nr/Makefile config.status: creating tests/test-string-r/Makefile config.status: creating tests/test-yyextra/Makefile config.status: creating tests/test-lineno-nr/Makefile config.status: creating tests/test-lineno-r/Makefile config.status: creating tests/test-linedir-r/Makefile config.status: creating tests/test-debug-r/Makefile config.status: creating tests/test-debug-nr/Makefile config.status: creating tests/test-mem-nr/Makefile config.status: creating tests/test-mem-r/Makefile config.status: creating tests/test-posix/Makefile config.status: creating tests/test-posixly-correct/Makefile config.status: creating tests/test-table-opts/Makefile config.status: creating tests/test-c++-basic/Makefile config.status: creating tests/test-bison-nr/Makefile config.status: creating tests/test-reject/Makefile config.status: creating tests/test-c++-multiple-scanners/Makefile config.status: creating tests/test-top/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing default-1 commands config.status: creating po/POTFILES config.status: creating po/Makefile config.status: executing depfiles commands |
From: Keith M. <kei...@to...> - 2006-01-20 11:44:54
|
Fl...@t-... wrote: > The problem is to combine those two steps like: "i586-mingw32msvc-gcc > -o lexan.exe lex.yy.c lexantest.c". Then the following message appears: > /tmp/ccksNSNQ.o:lex.yy.c:(.text+0x417): undefined reference to `_yywrap' > /tmp/ccksNSNQ.o:lex.yy.c:(.text+0xd42): undefined reference to `_yywrap' > collect2: ld returned 1 exit status > > As I once had this problem, somebody told me that I have to compile the > flex-source-package with: --target=i586-mingw32msvc option. Well, I've > tried this (you can have a look at the configure - Logfile output > below), but I'm not sure if it worked properly. Because there appear > lines saying: > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > > but no line telling the target system type. So I'm not sure, if the > target platform was detected properly. In order that it didn't worked > properly, can anybody please tell me the proper "configure call" ? > (like: ./configure --target=i586-mingw32msvc). My goal is, to develop > software on a linux box but for windows platforms. Is there something > else I have to pay attention when I want to use mingw32 together with > flex/bison. Any tips appreciated. I've no experience of flex or bison, but if your lexan.exe is to run on a Win32 host, don't you need a libfl.a which has been compiled for such a host? (i.e. `--host=i586-mingw32msvc', when you compile the flex sources to create this cross-compiled library)? AIUI, the build/host/target relationship works thus: * `build' is where you initially build some tools, which you intend to run on `host'. * `host' is where you subsequently use those tools, to create some other application, which will ultimately run elsewhere. * `target' is that ultimate `elsewhere'. BTW, why `i586-mingw32msvc-gcc'? My GNU/Linux hosted Win32 GCC, built using Michael Gerdau's script, is simply `i586-mingw32-gcc'. HTH, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-01-20 12:08:11
|
* Keith MARSHALL wrote on Fri, Jan 20, 2006 at 12:43:58PM CET: > > AIUI, the build/host/target relationship works thus: > > * `build' is where you initially build some tools, which you intend to > run on `host'. > > * `host' is where you subsequently use those tools, to create some > other application, which will ultimately run elsewhere. > > * `target' is that ultimate `elsewhere'. To clarify a bit further: target is specific to compilers and related tools that produce system-specific output. For example: On a GNU/Linux system ($build) I build a compiler that itself will run on FreeBSD ($host) but create code that can be executed on MinGW ($target). > BTW, why `i586-mingw32msvc-gcc'? My GNU/Linux hosted Win32 GCC, built > using Michael Gerdau's script, is simply `i586-mingw32-gcc'. I saw this, too, with a Debian package that provided this. I believe the $host_alias is somewhat up to the creator of the compiler. I don't know why the `msvc' part was added. Cheers, Ralf |
From: <Fl...@t-...> - 2006-01-20 13:27:59
|
Hey Keith, hey Ralf, thank you for fast response. To make it more clear: I'm using a linux debian system as developement platform. The application should run on windows platforms. Because of this I thought: Build = Host should be: i686-pc-linux-gnu and the Target: mingw32, respectively windows. Until now, I'm not very experienced with the options I have for --target. Maybe I have to use "windows", "winnt" or anything else ? I used "i586-mingw32msvc-gcc" only because this is exactly the way I call my compiler. As you both mentioned, it's normally mingw32-gcc I can only say that if I call it that way without 'msvc' I cannot call the compiler (and you're right, I'm using debian). As you asked, if I need the "libfl.a" compiled for the target host - yes I think so too. This is exactly the reason, why I want to compile the flex-sources to a target not equal linux. My goal is to get a "libfl.a" which can be included in my mingw32-call. Any further tips ? Thank you in advance, Ralf |
From: Ralf W. <Ral...@gm...> - 2006-01-20 13:37:47
|
* Fl...@t-... wrote on Fri, Jan 20, 2006 at 02:27:39PM CET: > > I'm using a linux debian system as developement platform. The > application should run on windows platforms. To make this very clear: the program `flex.exe' should be executed on mingw. Right? That means $host should contain mingw in its name. Flex generates source code, not object code. So for it, `target' is irrelevant. So, instead of this: > Because of this I thought: > Build = Host should be: i686-pc-linux-gnu > and the Target: mingw32, respectively windows. You should simply be using .../configure --host=i586-mingw32msvc [OPTIONS..] and be happy with it. The fact that `target' does not show up in the configure output is a strong hint that it is not relevant for this package. > Until now, I'm not very experienced with the options I have for > --target. Maybe I have to use "windows", "winnt" or anything else ? You should not be using --target at all. You are not creating a compiler. > As you asked, if I need the "libfl.a" compiled for the target host To be precise again: you may need it for the `host'. And yes, I believe that with above configure line, a libfl.a suitable for use on mingw should be created. > - yes I think so too. This is exactly the reason, why I want to > compile the flex-sources to a target not equal linux. Again, you mean `host not equal linux'. > My goal is to get a "libfl.a" which can be included in my > mingw32-call. Sorry for the pedantic comments, it's just that I easily get confused as well. Cheers, Ralf |
From: Keith M. <kei...@to...> - 2006-01-20 13:49:40
|
Fl...@t-... wrote: > As you asked, if I need the "libfl.a" compiled for the target host > - yes I think so too. This is exactly the reason, why I want to > compile the flex-sources to a target not equal linux. My goal is > to get a "libfl.a" which can be included in my mingw32-call. > > Any further tips ? Thank you in advance, You need to configure with `--build=i686-pc-linux-gnu' and with `--host=i586-mingw32msvc'. As I've already explained, with additional clarification from Ralf W, --target is really only applicable when there is a third architecture involved, e.g. you are building a cross-compiler to run on, say $host = FreeBSD, where *it* will create executables to run on (say) $target = Win32, but you are starting out on (say) $build = Linux, to build the FreeBSD-to-Win32 cross-compiler. Compile your flex sources, for $host = i586-mingw32msvc, to create a Win32 compatible libfl.a, then either use a -L switch to tell your i586-mingw32msvc-gcc where to find it, or drop it into the same directory as your i586-mingw32msvc libraries, to have it picked up automatically. HTH, Keith. |
From: <Fl...@t-...> - 2006-01-20 14:37:09
|
hey Keith, hey Ralf, I'm sorry for confusing both of you...! I'm afraid, that I have the wrong idea about how to realise my project. Let me explain, what I want to do in a broader sense: I want to write a rudimentary assembler software. This assembler software shall only do things like translating a simple assembler listing to an Opcode etc.. This software shall be executed on a windows platform. On the other hand I want to develop this assembler on a linux machine. So I have deal with two challenges: writing the assembler with the help of flex/bison AND make the programm work on windows. Because of this I first tried to compile a simple "Hello-World" Application on my linux machine with Mingw32 to achieve a console application for windows. After that, I thought; "ok, let's try this with an source code file produced by flex". And voila, there occured the problems. It was not possible to include the flex source file, because the lib (libfl.a) was generated for the linux platform and not for windows. Since then, I tried to generate a "windows-compatible" libfl.a and flex-programme, but it didn't work. To make it absolutely clear: I don't want to have a flex.exe application. I just want to use flex on a linux machine, but include the generated source code then to feed my "cross-compiler", that means i586-mingw32msvc-gcc. I hope this explanation was understandable now. The reason why I want to develop on a linux machine although the target machine is a windows one is, that I want to use QT later to generate a GUI. But this shall be step 2. I hope my idea is correct and realizable. If not, please tell me. Anyway, I tried the way you explained to me with --build=i686-pc-linux-gnu and --host=i586-mingw32msvc. The ./configure was OK, and it said: checking whether we are cross compiling... yes But when I called "make", it aborted soon...here the log: make all-recursive make[1]: Entering directory `/hd/downloads/mingw32source/objdir' Making all in . make[2]: Entering directory `/hd/downloads/mingw32source/objdir' if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../flex-2.5.31 -I. -DLOCALEDIR=\"/usr/local/share/locale\" -I/usr/local/include -I../flex-2.5.31/intl -g -O2 -MT libmain.o -MD -MP -MF ".deps/libmain.Tpo" \ -c -o libmain.o `test -f '../flex-2.5.31/libmain.c' || echo '../flex-2.5.31/'`../flex-2.5.31/libmain.c; \ then mv ".deps/libmain.Tpo" ".deps/libmain.Po"; \ else rm -f ".deps/libmain.Tpo"; exit 1; \ fi if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../flex-2.5.31 -I. -DLOCALEDIR=\"/usr/local/share/locale\" -I/usr/local/include -I../flex-2.5.31/intl -g -O2 -MT libyywrap.o -MD -MP -MF ".deps/libyywrap.Tpo" \ -c -o libyywrap.o `test -f '../flex-2.5.31/libyywrap.c' || echo '../flex-2.5.31/'`../flex-2.5.31/libyywrap.c; \ then mv ".deps/libyywrap.Tpo" ".deps/libyywrap.Po"; \ else rm -f ".deps/libyywrap.Tpo"; exit 1; \ fi rm -f libfl.a ar cru libfl.a libmain.o libyywrap.o i586-mingw32msvc-ranlib libfl.a if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../flex-2.5.31 -I. -DLOCALEDIR=\"/usr/local/share/locale\" -I/usr/local/include -I../flex-2.5.31/intl -g -O2 -MT ccl.o -MD -MP -MF ".deps/ccl.Tpo" \ -c -o ccl.o `test -f '../flex-2.5.31/ccl.c' || echo '../flex-2.5.31/'`../flex-2.5.31/ccl.c; \ then mv ".deps/ccl.Tpo" ".deps/ccl.Po"; \ else rm -f ".deps/ccl.Tpo"; exit 1; \ fi In file included from ../flex-2.5.31/ccl.c:34: ../flex-2.5.31/flexdef.h:73:19: regex.h: Datei oder Verzeichnis nicht gefunden ../flex-2.5.31/flexdef.h:205:1: warning: "INFINITY" redefined In file included from ../flex-2.5.31/flexdef.h:49, from ../flex-2.5.31/ccl.c:34: /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/include/math.h:289:1: warning: this is the location of the previous definition In file included from ../flex-2.5.31/ccl.c:34: ../flex-2.5.31/flexdef.h:1173: error: syntax error before "regex_linedir" ../flex-2.5.31/flexdef.h:1173: warning: data definition has no type or storage class ../flex-2.5.31/flexdef.h:1175: error: syntax error before '*' token ../flex-2.5.31/flexdef.h:1176: error: syntax error before '*' token ../flex-2.5.31/flexdef.h:1177: error: syntax error before '*' token ../flex-2.5.31/flexdef.h:1178: error: syntax error before '*' token ../flex-2.5.31/flexdef.h:1179: error: syntax error before '*' token ../flex-2.5.31/flexdef.h:1180: error: syntax error before '*' token make[2]: *** [ccl.o] Fehler 1 make[2]: Leaving directory `/hd/downloads/mingw32source/objdir' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/hd/downloads/mingw32source/objdir' make: *** [all] Fehler 2 root@acampc6:/hd/downloads/mingw32source/objdir# Hope this is not further confusing and saying "thanks again"... R@lf |
From: Keith M. <kei...@to...> - 2006-01-20 15:19:35
|
Fl...@t-... wrote: > To make it absolutely clear: I don't want to have a > flex.exe application. I just want to use flex on a linux machine, > but include the generated source code then to feed my > "cross-compiler", that means i586-mingw32msvc-gcc. Ok, that was clear to me anyway. But you run flex on GNU/Linux to produce intermediate source code, which you then must compile with the i586-mingw... cross-compiler, to generate a Win32 executable of your own application. That intermediate source code introduces an external symbol dependency, which is satisfied from libfl.a; since your executable will be for Win32, that libfl.a needs to be a Win32 object library, i.e. you must compile the library for a Win32 host, e.g. by using your i586-mingw32msvc-gcc. > Anyway, I tried the way you explained to me with > --build=i686-pc-linux-gnu and --host=i586-mingw32msvc. The ./configure > was OK, and it said: > checking whether we are cross compiling... yes That is the correct procedure. > But when I called "make", it aborted soon...here the log: > : > : > In file included from ../flex-2.5.31/ccl.c:34: > ../flex-2.5.31/flexdef.h:73:19: regex.h: Datei oder Verzeichnis nicht > gefunden > ../flex-2.5.31/flexdef.h:205:1: warning: "INFINITY" redefined > In file included from ../flex-2.5.31/flexdef.h:49, > from ../flex-2.5.31/ccl.c:34: > /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/include/math.h:289:1: > warning: this is the location of the previous definition > In file included from ../flex-2.5.31/ccl.c:34: > ../flex-2.5.31/flexdef.h:1173: error: syntax error before > "regex_linedir" > ../flex-2.5.31/flexdef.h:1173: warning: data definition has no type or > storage class > ../flex-2.5.31/flexdef.h:1175: error: syntax error before '*' token > ../flex-2.5.31/flexdef.h:1176: error: syntax error before '*' token > ../flex-2.5.31/flexdef.h:1177: error: syntax error before '*' token > ../flex-2.5.31/flexdef.h:1178: error: syntax error before '*' token > ../flex-2.5.31/flexdef.h:1179: error: syntax error before '*' token > ../flex-2.5.31/flexdef.h:1180: error: syntax error before '*' token > make[2]: *** [ccl.o] Fehler 1 > make[2]: Leaving directory `/hd/downloads/mingw32source/objdir' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Leaving directory `/hd/downloads/mingw32source/objdir' > make: *** [all] Fehler 2 Welcome to the world of software porting :-) My German is a bit rusty, but that looks like regex.h is missing, (and not checked for by configure, or conditionalised in the flex sources; naughty flex). Before you port flex to Win32, you need to port regex, (and then any other dependencies which show up). If that all seems like too much trouble, you might be able to find suitable precompiled Win32 libraries which someone else has already ported, and which you may be able to use. Search the web for likely candidates -- I've often found something I can use, ready made from the GnuWin32 project, at http://sourceforge.net/projects/gnuwin32 HTH, Keith. |
From: <Fl...@t-...> - 2006-01-20 16:14:07
|
Hey Keith, Ok, that was clear to me anyway. But you run flex on GNU/Linux to produce intermediate source code, which you then must compile with the i586-mingw... cross-compiler, to generate a Win32 executable of your own application. That intermediate source code introduces an external symbol dependency, which is satisfied from libfl.a; since your executable will be for Win32, that libfl.a needs to be a Win32 object library, i.e. you must compile the library for a Win32 host, e.g. by using your i586-mingw32msvc-gcc. => you got me exactly...!! :-) Welcome to the world of software porting :-) =>...I guess, now the trouble just started, right..?! :-| My German is a bit rusty, but that looks like regex.h is missing, => correct (and not checked for by configure, or conditionalised in the flex sources; naughty flex). Before you port flex to Win32, you need to port regex, (and then any other dependencies which show up). If that all seems like too much trouble, you might be able to find suitable precompiled Win32 libraries which someone else has already ported, and which you may be able to use. Search the web for likely candidates -- I've often found something I can use, ready made from the GnuWin32 project, at http://sourceforge.net/projects/gnuwin32 => I had a look at this site. There is a flex-2.5.4a-1-lib.zip - file available. So how does the procedure look like now ? Can I install the flex package the ordinary way (e.g. with apt-get install flex) and then afterwards copy the downloaded libfl.a to /usr/local/lib and the FlexLexer.h to /usr/local/include ? And then just call the cross-compiler like: "i586-mingw32-gcc -L /usr/local/lib -lfl -o lexan.exe lex.yy.c lexantest.c" ? Because if I have the Win32 lib then I do not need to compile the flex-sources the way I did, right ?! What do you think about alternatives Cygwin or MinGW for Windows to realise my intention ? Honestly I don't want to use this tools, on the other hand I didn't think that it is so complicated to set up a cross-compiling environment on a linux box. Thanks for your good advices... R@lf |
From: Igor Mikolic-T. <igo...@co...> - 2006-01-20 16:34:33
|
Hi, I do what you are trying to do: run flex on linux, cross-compile the flex output on linux to produce a Win32 executable. Here is what I did. (1) Use the normal "linux" flex to generate the code. (2) Get the GnuWin32 project "flex", extract libfl.a, and copy it to a directory where my cross-compiler can find it (and make sure it doesn't get confused with the linux version!) In my case I keep Win32 libs for use with the cross-compiler in /usr/local/mingw32/lib. (3) pass -lfl and -L<as needed> to the cross-compiler. Do check that the versions for the linux flex and the GnuWin32 flex are the same (or at least close -- check the release notes to determine what "close enough" is). Igor Fl...@t-... wrote: > Hey Keith, > > Ok, that was clear to me anyway. But you run flex on GNU/Linux to > produce intermediate source code, which you then must compile with > the i586-mingw... cross-compiler, to generate a Win32 executable > of your own application. That intermediate source code introduces > an external symbol dependency, which is satisfied from libfl.a; > since your executable will be for Win32, that libfl.a needs to be > a Win32 object library, i.e. you must compile the library for a > Win32 host, e.g. by using your i586-mingw32msvc-gcc. > => you got me exactly...!! :-) > > Welcome to the world of software porting :-) > =>...I guess, now the trouble just started, right..?! :-| > > My German is a bit rusty, but that looks like regex.h is missing, > => correct > (and not checked for by configure, or conditionalised in the flex > sources; naughty flex). Before you port flex to Win32, you need > to port regex, (and then any other dependencies which show up). > > If that all seems like too much trouble, you might be able to find > suitable precompiled Win32 libraries which someone else has already > ported, and which you may be able to use. Search the web for likely > candidates -- I've often found something I can use, ready made from > the GnuWin32 project, at http://sourceforge.net/projects/gnuwin32 > > => I had a look at this site. There is a flex-2.5.4a-1-lib.zip - file > available. So how does the procedure look like now ? Can I install the > flex package the ordinary way (e.g. with apt-get install flex) and then > afterwards copy the downloaded libfl.a to /usr/local/lib and the > FlexLexer.h to /usr/local/include ? And then just call the > cross-compiler like: > "i586-mingw32-gcc -L /usr/local/lib -lfl -o lexan.exe lex.yy.c > lexantest.c" ? > Because if I have the Win32 lib then I do not need to compile the > flex-sources the way I did, right ?! > > What do you think about alternatives Cygwin or MinGW for Windows to > realise my intention ? Honestly I don't want to use this tools, on the > other hand I didn't think that it is so complicated to set up a > cross-compiling environment on a linux box. > > Thanks for your good advices... > > R@lf > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Keith M. <kei...@to...> - 2006-01-20 17:34:55
|
Fl...@t-... wrote, quoting me: >> If that all seems like too much trouble, you might be able to find >> suitable precompiled Win32 libraries which someone else has already >> ported, and which you may be able to use. Search the web for likely >> candidates -- I've often found something I can use, ready made from >> the GnuWin32 project, at http://sourceforge.net/projects/gnuwin32 > > I had a look at this site. There is a flex-2.5.4a-1-lib.zip - file > available. So how does the procedure look like now ? Can I install the > flex package the ordinary way (e.g. with apt-get install flex)... That will get you a Linux-native flex, which of course is what you want for the lexer itself; but you already have that, have you not? (OTOH, if you are thinking of apt-get to extract the GnuWin32 package, then no, you unpack it somewhere convenient, using a zip file extractor: ark should do it, if you are using KDE; I don't know what the equivalent for Gnome, or any other desktop environment, is). > ... and then > afterwards copy the downloaded libfl.a to /usr/local/lib and the > FlexLexer.h to /usr/local/include ? And then just call the > cross-compiler like: > "i586-mingw32-gcc -L /usr/local/lib -lfl -o lexan.exe lex.yy.c > lexantest.c" ? Your native Linux installation will likely have provided a native libfl.a, which will likely reside in /usr/local/lib. It isn't a good idea to mix Win32 and Linux native libraries in the same directory. Rather extract the required Win32 library from the GnuWin32 package, and put it in a lib directory within your i586-mingw32msvc tree. Same applies to the header files; keep those related to the cross-compiler's libs separate from those belonging to your native compiler. > Because if I have the Win32 lib then I do not need to compile the > flex-sources the way I did, right ?! You got it. If it's already compiled, you should just need to let the i586-mingw32msvc-gcc linker know where to find it. Of course, you may then find other symbol dependencies, for which you will have to find other libraries, before you get everything resolved... > What do you think about alternatives Cygwin or MinGW for Windows to > realise my intention? Only you can decide if these would suit you better. > Honestly I don't want to use this tools, on the > other hand I didn't think that it is so complicated to set up a > cross-compiling environment on a linux box. Given the choice, I would go for GNU/Linux every time; unfortunately, I don't always have that choice ;-( I built my entire MinGW-cross GCC from the MinGW sources, using Michael Gerdau's build script; it took about an hour to get it all set up, on a 650MHz AMD-Duron box, under a substantially updated Mandrake 8.2. I've even adapted the mingwPORT framework, so that I can build Win32 binary packages from the mingwPORTs, (which officially require MSYS on Win32), without leaving the comfort of my GNU/Linux platform :-) Cheers, Keith. |
From: Ralf E. <fl...@t-...> - 2006-01-20 19:35:06
|
hey Keith, hey Igor, thank you again for your tips. OK, I will try it the way you suggest. Hopefully it will work then. If I add the path to the Win32 libfl.a, shall I delete all the other links to the "native libfl.a" ? What´s the best way to add / remove the links in the search-path of the compiler / linker. I only know "--print-search-dirs", but I don´t know how to modify the entries then. Hey guys, I think you saved my weekend ! :-)) R@lf |
From: Keith M. <kei...@us...> - 2006-01-20 23:33:21
|
On Friday 20 January 2006 7:34 pm, Ralf Emberger wrote: > If I add the path to the Win32 libfl.a, shall I delete all the other > links to the "native libfl.a" ? If you've installed your i586-mingw32msvc-gcc tool chain correctly, (and presumably, if you used apt, this will be the case), it will have its own set of headers and libraries. These will be installed in a completely different location, physically separated from the equivalent files used by your native Linux compiler. For example, my native GCC headers are in /usr/include and /usr/local/include, with libraries in /usr/lib and /usr/local/include; for my i586-mingw32-gcc, the headers and libraries are in $HOME/mingw/i586-mingw32/include, and $HOME/mingw/i586-mingw32/lib respectively; (I installed the cross-compiler for my personal use only). Each compiler will be configured, through independent specs files, to search in the appropriate places for its default headers and libraries. Since these are kept physically separated, you don't need to worry about specifying the correct locations; this will happen automatically, and the correct versions will always be used in each case. Where you *do* need to pay attention is to libraries, or associated headers, which you are supplying yourself. Adopt the same strategy as the compilers do for their default files, and keep your native Linux and Win32-cross files physically separated, and you won't go wrong. Never mix native and Win32-cross builds in the same build directory. When you need to supply -I or -L switches, point them exclusively to directories where you have only native headers or libraries, when you compile a native application; conversely, point them to directories where you have only Win32 headers and libraries, when you perform a cross-compile with i586-mingw32msvc tools. This way, there can never be any conflict. HTH, Keith. |
From: Ralf E. <fl...@t-...> - 2006-01-21 10:10:47
|
hey Keith, seems like this turns to a never ending story. I´ve tried your suggestions today. The result is not like expected. What I did: 1) I first checked the search-path of my i586-mingw32msvc-gcc Compiler. In none of the paths there is anywhere the native libfl.a. 2) I´ve created a new dir on: /hd/programming/win32libs/lib and /hd/programming/win32libs/include 3) I´ve copied the libfl.a from the GnuWin32 project to ../lib and the FlexLexer.h to ../include 4) then I called my cross-compiler with the following: "i586-mingw32msvc-gcc -L/hd/programming/win32libs/lib -lfl -o lexan.exe lex.yy.c lexantest.c" in order to tell my cross-compiler where it can find the Win32-Lib. The result I get then is almost the same as it was before: /tmp/ccABhXHO.o:lexantest.c:(.text+0x0): multiple definition of `_main' /hd/programming/win32libs/lib/libfl.a(libmain.o):libmain.c:(.text+0x0): first defined here /tmp/cctdKjz1.o:lex.yy.c:(.text+0x417): undefined reference to `_yywrap' /tmp/cctdKjz1.o:lex.yy.c:(.text+0xd42): undefined reference to `_yywrap' collect2: ld returned 1 exit status Does this make any sense ? Or are there any mistakes I made in realising what you and Igor have suggested to me yesterday? Thank you, Ralf |
From: Keith M. <kei...@us...> - 2006-01-21 17:26:37
|
On Saturday 21 January 2006 10:10 am, Ralf Emberger wrote: > 4) then I called my cross-compiler with the following: > "i586-mingw32msvc-gcc -L/hd/programming/win32libs/lib -lfl -o lexan.exe > lex.yy.c lexantest.c" in order to tell my cross-compiler where it can > find the Win32-Lib. The result I get then is almost the same as it was > before: .... Ralf, Everything you've done looks correct, up until here. The order of the args on the compiler command line is important -- -lfl must come *after* the names of the source (or object) files which reference it, so you need: i586-mingw32msvc-gcc -L/hd/programming/win32libs/lib -o lexan.exe \ lex.yy.c lexantest.c -lfl Regards, Keith. |
From: Michael B. <mic...@gm...> - 2006-01-20 20:54:19
|
Hi Rolf, We had the same discussion with R@olf in October 2005, I think around 20th. If I remember correctly the solution to the problem was provided then by Brian. This issue pops up priodically in this forum.......... Michael. Fl...@t-... wrote: > > |