Winflex
in [PgSql]
|
Prev: Largeobject Access Controls (r2460)
Next: Range types
From: Andrew Dunstan on 12 Dec 2009 15:19 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 12 Dec 2009 15:24 On Sat, Dec 12, 2009 at 21:19, Andrew Dunstan <andrew(a)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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 13 Dec 2009 00:42 Magnus Hagander wrote: > On Sat, Dec 12, 2009 at 21:19, Andrew Dunstan <andrew(a)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(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 13 Dec 2009 05:36 On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew(a)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(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 13 Dec 2009 06:29
On Sun, Dec 13, 2009 at 11:36, Dave Page <dpage(a)pgadmin.org> wrote: > On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew(a)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(a)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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |