Flex tool issue

[GoogleCodeExporter]

I'm having problems with the flex tool when generating parse.l both from 
VS and the command line:
1>flex: fatal internal error, exec failed

E:\ossbuild\Tools>flex -P_gst_parse_yy -o"E:\ossbuild\Build\Windows\Win32
\Debug
\obj\gstreamer\common\parse.c" "e:\ossbuild\Main\GStreamer\Source\gstreamer
\gst\
parse\parse.l"
flex: fatal internal error, exec failed

Original issue reported on code.google.com by david.g.hoyt on 27 Apr 2009 at 3:10

[GoogleCodeExporter]

Which OS are you using? I've had no problems on any WinXP 32-bit machine I've 
tested 
it on. But the flex/bison tools don't work on 64-bit machines due to some 
issues 
with the emulated forking on msys/cygwin apps. It's possible I have a system 
library 
installed that I forgot to include. Can you provide more information?

I've considered moving all the auto-generated stuff to a separate project, 
distributing the auto-generated items w/ everything else, and then only re-
generating it if it changes. Doing it the way I have it causes issues w/ 
rebuilds 
b/c when a file is auto-generated, it causes all dependent projects to be 
rebuilt 
b/c msbuild only looks at last modified timestamps instead of timestamp + 
content. 
It also would mean that we would only have to have flex/bison/etc. working in a 
known environment (for Windows). It would still be required for Linux/OSX, 
though.

Original comment by david.g.hoyt on 27 Apr 2009 at 3:19

[GoogleCodeExporter]

I'm using Windows XP 32 bits, on a 64 bits machine. I think it has nothing to 
do 
with the architecture, because the flex tool works with OAbuild. 
I have tryed to replace flex.exe in ossbuild, but I get the same error. 
I think the error might be caused by a too long path that may cause a buffer 
overflow.
I will try to do like OAbuild does, this is "cd" to the sources dir (or to the 
output dir), ans then call flex. This way you reduce args' length.

Original comment by ylatuya on 27 Apr 2009 at 12:37

[GoogleCodeExporter]

The changes I have proposed doesn't work.
I have tryed to use the generate file by GStream-Winbuilds but I get some 
unresovled
symbols:
errorsError 106 error LNK2019: unresolved external symbol 
__gst_parse_yy_scan_string
referenced in function __gst_parse_launch   grammar.tab.obj

Can you deploy this file instead of generating it.

Original comment by ylatuya on 29 Apr 2009 at 3:04

[GoogleCodeExporter]

I'll get the changes as I proposed ASAP.

Original comment by david.g.hoyt on 29 Apr 2009 at 5:22

[GoogleCodeExporter]

I'm partway into this. I've got the basic infrastructure for generating the 
files 
down, now I just need to get the complete list of files to generate and 
integrate it 
with the visual studio projects.

Original comment by david.g.hoyt on 5 May 2009 at 3:36

[GoogleCodeExporter]

The flex error is b/c m4 is in a nonstandard place. If you set the environment 
variable M4 to point at the m4 executable, it should work.

At any rate, I have the pre-generated files in the repo now (as of rev 106). 
When 
you get the time, please look at updating the farsight stuff. If I have time, 
I'll 
try and do it - but I haven't been able to even look at it yet.

Original comment by david.g.hoyt on 5 May 2009 at 9:34

• Changed state: Fixed

[GoogleCodeExporter]

The farsight stuff is already updated, and the compilation is going well.

Original comment by ylatuya on 5 May 2009 at 9:41