Re: 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 Hagander
Me: 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(at)dunslane(dot)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/

Magnus Hagander wrote:
> On Sat, Dec 12, 2009 at 21:19, Andrew Dunstan <andrew(at)dunslane(dot)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(at)cygwin(dot)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(at)dunslane(dot)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(at)cygwin(dot)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(at)pgadmin(dot)org> wrote:
> On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew(at)dunslane(dot)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(at)cygwin(dot)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/

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):
> On Sun, Dec 13, 2009 at 11:36, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew(at)dunslane(dot)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(at)cygwin(dot)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 think the actual problem is the implementation of fork emulation which
changed in 1.7.

>>> I can try again with Cygwin 1.7. and see if that improves matters, but I bet
>>> it doesn't.
>>>

Cygwin 1.7.0-52 (iirc) with flex works for me on x64 Vista.

>> 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)
>

No they have newest flex, but the whole thing is even more broken on
64bit then (old) cygwin version - it just exits without doing anything
and does not even report any errors.

--
Regards
Petr Jelinek (PJMODOS)

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(at)hagander(dot)net> wrote:
> On Sun, Dec 13, 2009 at 11:36, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Sun, Dec 13, 2009 at 5:42 AM, Andrew Dunstan <andrew(at)dunslane(dot)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(at)cygwin(dot)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(at)dunslane(dot)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