Обсуждение: Winflex
Using http://www.postgresql.org/ftp/misc/winflex/ on a 64-bit windows, but in 32-bit mode (this certainly used to work), trying to build HEAD. first of all, it returns error code 128 when running "flex -V", which means our script claims it doesn't work. Commenting out that check, it crashes along the line of: Running flex on src\backend\utils\misc\guc-file.l 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION Sometimes it doesn't crash, but do this instead: Running flex on src\backend\parser\scan.l c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string Project : error PRJ0002 : Error result 128 returned from 'C:\WINDOWS\SysWow64\cm d.exe'. If I run it a couple of times, it eventually completes. But then bombs out because the generated files aren't complete. Anybody else seen this? Am I forgetting something typical? -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > Using > http://www.postgresql.org/ftp/misc/winflex/ > > on a 64-bit windows, but in 32-bit mode (this certainly used to work), > trying to build HEAD. > > first of all, it returns error code 128 when running "flex -V", which > means our script claims it doesn't work. Commenting out that check, it > crashes along the line of: > Running flex on src\backend\utils\misc\guc-file.l > 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: > STATUS_ACCESS_VIOLATION > > Sometimes it doesn't crash, but do this instead: > Running flex on src\backend\parser\scan.l > c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string > Project : error PRJ0002 : Error result 128 returned from 'C:\WINDOWS\SysWow64\cm > d.exe'. > > > If I run it a couple of times, it eventually completes. But then bombs > out because the generated files aren't complete. > > Anybody else seen this? Am I forgetting something typical? > Hmm. I don't have a 64bit Windows box, so I doubt I can test this. I can set up a 64bit VM but I'd need to get my hands on a 64bit version of Windows. cheers andrew
On Sat, Dec 12, 2009 at 21:19, Andrew Dunstan <andrew@dunslane.net> wrote: > > > Magnus Hagander wrote: >> >> Using >> http://www.postgresql.org/ftp/misc/winflex/ >> >> on a 64-bit windows, but in 32-bit mode (this certainly used to work), >> trying to build HEAD. >> >> first of all, it returns error code 128 when running "flex -V", which >> means our script claims it doesn't work. Commenting out that check, it >> crashes along the line of: >> Running flex on src\backend\utils\misc\guc-file.l >> 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: >> STATUS_ACCESS_VIOLATION >> >> Sometimes it doesn't crash, but do this instead: >> Running flex on src\backend\parser\scan.l >> c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string >> Project : error PRJ0002 : Error result 128 returned from >> 'C:\WINDOWS\SysWow64\cm >> d.exe'. >> >> >> If I run it a couple of times, it eventually completes. But then bombs >> out because the generated files aren't complete. >> >> Anybody else seen this? Am I forgetting something typical? >> > > Hmm. > > I don't have a 64bit Windows box, so I doubt I can test this. I can set up a > 64bit VM but I'd need to get my hands on a 64bit version of Windows. I use Amazon EC2 for this. Trivial to get up, and almost free when you use it for very short periods of time. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Sat, Dec 12, 2009 at 21:19, Andrew Dunstan <andrew@dunslane.net> wrote: > >> Magnus Hagander wrote: >> >>> Using >>> http://www.postgresql.org/ftp/misc/winflex/ >>> >>> on a 64-bit windows, but in 32-bit mode (this certainly used to work), >>> trying to build HEAD. >>> >>> first of all, it returns error code 128 when running "flex -V", which >>> means our script claims it doesn't work. Commenting out that check, it >>> crashes along the line of: >>> Running flex on src\backend\utils\misc\guc-file.l >>> 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: >>> STATUS_ACCESS_VIOLATION >>> >>> Sometimes it doesn't crash, but do this instead: >>> Running flex on src\backend\parser\scan.l >>> c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string >>> Project : error PRJ0002 : Error result 128 returned from >>> 'C:\WINDOWS\SysWow64\cm >>> d.exe'. >>> >>> >>> If I run it a couple of times, it eventually completes. But then bombs >>> out because the generated files aren't complete. >>> >>> Anybody else seen this? Am I forgetting something typical? >>> >>> >> Hmm. >> >> I don't have a 64bit Windows box, so I doubt I can test this. I can set up a >> 64bit VM but I'd need to get my hands on a 64bit version of Windows. >> > > I use Amazon EC2 for this. Trivial to get up, and almost free when you > use it for very short periods of time. > Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are hosed on 64bit Windows. I can't get flex built and Cygwin is behaving very oddly. There are indications that the problem could be fairly deep - see <http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html> I can try again with Cygwin 1.7. and see if that improves matters, but I bet it doesn't. cheers andrew
On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > > Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are > hosed on 64bit Windows. I can't get flex built and Cygwin is behaving very > oddly. There are indications that the problem could be fairly deep - see > <http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html> What Linda describes there is all normal behaviour for a 32 bit app on 64 bit Windows. Windows is providing a virtual 32 bit environment, where for the most part the 32 bit app doesn't realise it's running on 64 bit. Unfortunately there are always things that look a bit odd due to this, but normally I've found that the 32bit code runs fine, it just looks odd from Explorer or 64 bit apps because of the folder/registry redirection that happens behind the scenes. > I can try again with Cygwin 1.7. and see if that improves matters, but I bet > it doesn't. What about msys? Or is that not capable of building the newer versions of flex? The other possible option that I hesitate to suggest is Windows Services for Unix or SUA as I think it's now called. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Sun, Dec 13, 2009 at 11:36, Dave Page <dpage@pgadmin.org> wrote: > On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >> >> Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are >> hosed on 64bit Windows. I can't get flex built and Cygwin is behaving very >> oddly. There are indications that the problem could be fairly deep - see >> <http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html> > > What Linda describes there is all normal behaviour for a 32 bit app on > 64 bit Windows. Windows is providing a virtual 32 bit environment, > where for the most part the 32 bit app doesn't realise it's running on > 64 bit. Unfortunately there are always things that look a bit odd due > to this, but normally I've found that the 32bit code runs fine, it > just looks odd from Explorer or 64 bit apps because of the > folder/registry redirection that happens behind the scenes. Yeah, none of that should have an effect on a tool like "flex", though... >> I can try again with Cygwin 1.7. and see if that improves matters, but I bet >> it doesn't. Sounds like it's worth a try - they seem to at least know the issues detect. > What about msys? Or is that not capable of building the newer versions of flex? IIRC we looked at that before, and that one is also limited to the version before they started doing fork() (that was the problem with the newer ones and gnuwin32, iirc) > The other possible option that I hesitate to suggest is Windows > Services for Unix or SUA as I think it's now called. You mean we should post flex to that? Or have you found someone who has already? -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > Using > http://www.postgresql.org/ftp/misc/winflex/ > > on a 64-bit windows, but in 32-bit mode (this certainly used to work), > trying to build HEAD. > > first of all, it returns error code 128 when running "flex -V", which > means our script claims it doesn't work. Commenting out that check, it > crashes along the line of: > Running flex on src\backend\utils\misc\guc-file.l > 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: > STATUS_ACCESS_VIOLATION > > Sometimes it doesn't crash, but do this instead: > Running flex on src\backend\parser\scan.l > c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string > Project : error PRJ0002 : Error result 128 returned from 'C:\WINDOWS\SysWow64\cm > d.exe'. > > > If I run it a couple of times, it eventually completes. But then bombs > out because the generated files aren't complete. > > Anybody else seen this? Am I forgetting something typical? > Well, I have now reproduced the behaviour, so it's not just you. But I have not been able to set up a working Cygwin build environment, so I can't try to rebuild it right now. It sure looks like it's the exec that's failing. cheers andrew
Magnus Hagander napsal(a): <blockquote cite="mid:9837222c0912130329i1eb8d075u7996b4f92b41390a@mail.gmail.com" type="cite"><prewrap="">On Sun, Dec 13, 2009 at 11:36, Dave Page <a class="moz-txt-link-rfc2396E" href="mailto:dpage@pgadmin.org"><dpage@pgadmin.org></a>wrote: </pre><blockquote type="cite"><pre wrap="">On Sun, Dec13, 2009 at 5:42 AM, Andrew Dunstan <a class="moz-txt-link-rfc2396E" href="mailto:andrew@dunslane.net"><andrew@dunslane.net></a>wrote: </pre><blockquote type="cite"><pre wrap="">Yes.I spent a few cents and a few hours wrestling with it. AFAICT your are hosed on 64bit Windows. I can't get flex built and Cygwin is behaving very oddly. There are indications that the problem could be fairly deep - see <a class="moz-txt-link-rfc2396E" href="http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html"><http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html></a> </pre></blockquote><pre wrap="">What Linda describes there is all normal behaviour for a 32 bit app on 64 bit Windows. Windows is providing a virtual 32 bit environment, where for the most part the 32 bit app doesn't realise it's running on 64 bit. Unfortunately there are always things that look a bit odd due to this, but normally I've found that the 32bit code runs fine, it just looks odd from Explorer or 64 bit apps because of the folder/registry redirection that happens behind the scenes. </pre></blockquote><pre wrap=""> Yeah, none of that should have an effect on a tool like "flex", though... </pre></blockquote><br /> I think the actual problemis the implementation of fork emulation which changed in 1.7.<br /><br /><br /><blockquote cite="mid:9837222c0912130329i1eb8d075u7996b4f92b41390a@mail.gmail.com"type="cite"><blockquote type="cite"><blockquote type="cite"><prewrap="">I can try again with Cygwin 1.7. and see if that improves matters, but I bet it doesn't. </pre></blockquote></blockquote><pre wrap=""></pre></blockquote><br /> Cygwin 1.7.0-52 (iirc) with flex worksfor me on x64 Vista.<br /><br /><br /><blockquote cite="mid:9837222c0912130329i1eb8d075u7996b4f92b41390a@mail.gmail.com"type="cite"><blockquote type="cite"><pre wrap="">Whatabout msys? Or is that not capable of building the newer versions of flex? </pre></blockquote><pre wrap=""> IIRC we looked at that before, and that one is also limited to the version before they started doing fork() (that was the problem with the newer ones and gnuwin32, iirc) </pre></blockquote><br /> No they have newest flex, but the whole thing is even more brokenon 64bit then (old) cygwin version - it just exits without doing anything and does not even report any errors.<br /><br/><pre class="moz-signature" cols="72">-- Regards Petr Jelinek (PJMODOS)</pre>
Petr Jelinek wrote: > > Cygwin 1.7.0-52 (iirc) with flex works for me on x64 Vista. Can you let me have the flex.exe and cygwin1.dll that I can try on a virgin WinS2k3 64-bit box? It will probably need to be configured with --disable-nls. cheers andrew
Andrew Dunstan napsal(a): > > > Petr Jelinek wrote: >> >> Cygwin 1.7.0-52 (iirc) with flex works for me on x64 Vista. > > > Can you let me have the flex.exe and cygwin1.dll that I can try on a > virgin WinS2k3 64-bit box? > > It will probably need to be configured with --disable-nls. This is the version I am using (probably not newest one or anything, but I used it for testing all of my patches for 8.5 and I tried it successfully today on git head). http://pjmodos.parba.cz/temp/cygflex.zip -- Regards Petr Jelinek (PJMODOS)
Petr Jelinek wrote: > Andrew Dunstan napsal(a): >> >> >> Petr Jelinek wrote: >>> >>> Cygwin 1.7.0-52 (iirc) with flex works for me on x64 Vista. >> >> >> Can you let me have the flex.exe and cygwin1.dll that I can try on a >> virgin WinS2k3 64-bit box? >> >> It will probably need to be configured with --disable-nls. > > This is the version I am using (probably not newest one or anything, > but I used it for testing all of my patches for 8.5 and I tried it > successfully today on git head). > http://pjmodos.parba.cz/temp/cygflex.zip Sadly this still gives me: flex: fatal internal error, exec failed on WinS2K3 64bit on EC2. cheers andrew
On Sun, Dec 13, 2009 at 11:29 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Sun, Dec 13, 2009 at 11:36, Dave Page <dpage@pgadmin.org> wrote: >> On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >>> >>> Yes. I spent a few cents and a few hours wrestling with it. AFAICT your are >>> hosed on 64bit Windows. I can't get flex built and Cygwin is behaving very >>> oddly. There are indications that the problem could be fairly deep - see >>> <http://www.mail-archive.com/cygwin@cygwin.com/msg102463.html> >> >> What Linda describes there is all normal behaviour for a 32 bit app on >> 64 bit Windows. Windows is providing a virtual 32 bit environment, >> where for the most part the 32 bit app doesn't realise it's running on >> 64 bit. Unfortunately there are always things that look a bit odd due >> to this, but normally I've found that the 32bit code runs fine, it >> just looks odd from Explorer or 64 bit apps because of the >> folder/registry redirection that happens behind the scenes. > > Yeah, none of that should have an effect on a tool like "flex", though... Thats my point. >> The other possible option that I hesitate to suggest is Windows >> Services for Unix or SUA as I think it's now called. > > You mean we should post flex to that? Or have you found someone who has already? No idea if someone has done it already. I'm just throwing it out there as an idea possibly worthy of further investigation. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > >>> The other possible option that I hesitate to suggest is Windows >>> Services for Unix or SUA as I think it's now called. >>> >> You mean we should post flex to that? Or have you found someone who has already? >> > > No idea if someone has done it already. I'm just throwing it out there > as an idea possibly worthy of further investigation. > Don't you need to have SUA installed to run a program built with SUA? Or are you suggesting we can build a distributable flex executable with SUA which would run standalone (as I did for 32bit Windows using Cygwin)? Requiring developers to install SUA would be quite a siginificant extra burden, ISTM. cheers andrew
On Mon, Dec 14, 2009 at 12:10 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > Dave Page wrote: >> >> >>>> >>>> The other possible option that I hesitate to suggest is Windows >>>> Services for Unix or SUA as I think it's now called. >>>> >>> >>> You mean we should post flex to that? Or have you found someone who has >>> already? >>> >> >> No idea if someone has done it already. I'm just throwing it out there >> as an idea possibly worthy of further investigation. >> > > > Don't you need to have SUA installed to run a program built with SUA? Or are > you suggesting we can build a distributable flex executable with SUA which > would run standalone (as I did for 32bit Windows using Cygwin)? Requiring > developers to install SUA would be quite a siginificant extra burden, ISTM. The latter. And I have no idea if it's actually an option - just throwing it out there as an idea. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Magnus Hagander wrote: > Using > http://www.postgresql.org/ftp/misc/winflex/ > > on a 64-bit windows, but in 32-bit mode (this certainly used to work), > trying to build HEAD. > > first of all, it returns error code 128 when running "flex -V", which > means our script claims it doesn't work. Commenting out that check, it > crashes along the line of: > Running flex on src\backend\utils\misc\guc-file.l > 14 [main] flex 2372 _cygtls::handle_exceptions: Exception: > STATUS_ACCESS_VIOLATION > > Sometimes it doesn't crash, but do this instead: > Running flex on src\backend\parser\scan.l > c:\gnuwin32\bin\m4.exe:stdin:16769: ERROR: end of file in string > Project : error PRJ0002 : Error result 128 returned from 'C:\WINDOWS\SysWow64\cm > d.exe'. > > > If I run it a couple of times, it eventually completes. But then bombs > out because the generated files aren't complete. > > Anybody else seen this? Am I forgetting something typical? > > [6 months later ...] I have upgraded the winflex binaries (and the accompanying source tarball) to use version 1.7.5-1 of cygwin1.dll, after confirming that this works properly on both 64-bit and 32-bit windows. It should be on its way out to the mirrors. A shortcut would be to grab the DLL from <http://developer.postgresql.org/~adunstan/cygwin1.dll> and drop it in the directory with flex.exe. This DLL will disappear in a few days. cheers andrew