flex for windows

[Gus Gassmann]

I am trying to contribute to a large project and am running into a bit
of a problem.

One of the lex files uses %option reentrant, which flex refuses to
compile. I am running version 2.5.4 under windows. From what I can
gather, this is a rather old version, but I have not been able to find
newer binaries.
Is there a download out there for version 2.5.33? Also, can someone
confirm that %option reentrant works with 2.5.33?

Thanks a million, and sorry if this is a FAQ.

[Tor Rustad]

Gus Gassmann wrote:

I am trying to contribute to a large project and am running into a bit
of a problem.

One of the lex files uses %option reentrant, which flex refuses to
compile. I am running version 2.5.4 under windows. From what I can
gather, this is a rather old version, but I have not been able to find
newer binaries.

Yeah, I have 2.5.33 installed on current machine.

Is there a download out there for version 2.5.33? Also, can someone
confirm that %option reentrant works with 2.5.33?

flex issues are off-topic for c.l.c, one option might be running flex on
Linux, and then check if the C sources generated, compile on your
current environment.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[julien.hamaide]

On Dec 12, 4:32 pm, Gus Gassmann <[e-mail]:

I am trying to contribute to a large project and am running into a bit
of a problem.

One of the lex files uses %option reentrant, which flex refuses to
compile. I am running version 2.5.4 under windows. From what I can
gather, this is a rather old version, but I have not been able to find
newer binaries.
Is there a download out there for version 2.5.33? Also, can someone
confirm that %option reentrant works with 2.5.33?

Hi,

I ran into the same problems some time ago. The only solution I found
was to compile a newer version using cygwin. I haven't found any
binaries of the 2.5.33 for windows at that time.

The biggest problem with the cygwin version is that you have to use
cygwin path for windows drives such as /cygdrive/c/ . If somebody has
another solution, I'm also interested in it.

Julien Hamaide

[Tim Prince]

>One of the lex files uses %option reentrant, which flex refuses to

>compile. I am running version 2.5.4 under windows. ...

I ran into the same problems some time ago. The only solution I found
was to compile a newer version using cygwin. I haven't found any
binaries of the 2.5.33 for windows at that time.

The biggest problem with the cygwin version is that you have to use
cygwin path for windows drives such as /cygdrive/c/ . If somebody has
another solution, I'm also interested in it.

It looks like you have to run 'make check' inside cygwin anyway, or
discount environmental failures. You haven't specified what problem
you have in mind for "another solution." There are plenty of hints on
line about building or downloading flex for mingw, in case, for some
reason, you don't want to use the cygwin version.

[Tim Prince]

>One of the lex files uses %option reentrant, which flex refuses to

>compile. I am running version 2.5.4 under windows. ...

I ran into the same problems some time ago. The only solution I found
was to compile a newer version using cygwin. I haven't found any
binaries of the 2.5.33 for windows at that time. ...

Part of the problem seems to be that flex has added features which
can't be supported fully without some posix environment. There are
plenty of suggestions on line about flex for mingw. You can't say you
want cygwin capabilities and in the same breath you want everything to
happen automagically without them.

[Hans-Peter Diettrich]

Tim Prince wrote:

Part of the problem seems to be that flex has added features which
can't be supported fully without some posix environment. There are
plenty of suggestions on line about flex for mingw. You can't say you
want cygwin capabilities and in the same breath you want everything to
happen automagically without them.

I don't think that a tool like flex really depends on special POSIX
features, apart from the file handling. More problems will result from
the autobloat implementation, where more platform specific (filesystem
related) features may be required.

My solution for that problem is a Linux box, where ./configure already
works, then compiling the configured sources under the actual target
system (Windows), with "native" tools. Cygwin and MinGW frequently
fail to configure, with ridiculous error messages like "compiler
cannot create executable files". In most cases it's sufficient to link
the result with Windows-specific wrappers around fopen() and similar
filesystem specific functions, to make the code work.

DoDi

[Gus Gassmann]

On 13 Dec, 08:12, Tim Prince <[e-mail]:

One of the lex files uses %option reentrant, which flex refuses to
compile. I am running version 2.5.4 under windows. ...

I ran into the same problems some time ago. The only solution I found
was to compile a newer version using cygwin. I haven't found any
binaries of the 2.5.33 for windows at that time. ...

Part of the problem seems to be that flex has added features which
can't be supported fully without some posix environment. There are
plenty of suggestions on line about flex for mingw. You can't say you
want cygwin capabilities and in the same breath you want everything to
happen automagically without them.

Can't say I understand any of this. Someone handed me a .l file with
%option reentrant in it. I work in a Windows environment, but I have
to get that .l file compiled somehow.

Following this discussion, I found mingw and thought I installed it; I
downloaded flex 2.5.33 and thought I installed it, but it complains
that it can't find a .dll called msys-regex-0.dll. Now what?

Is there anyone kind (and knowledgeable) enough to help out a
desperate soul in a fix? I know I am asking for a lot, but I am hoping
that there is somewhere in this great world that is the internet a
step by step procedure I can follow. (As in 1. Download this file from
here. 2. Install to that directory. 3. Download and install that file
there. etc.)

Thanks a million.

gus

[tim prince]

Hans-Peter Diettrich wrote:

Tim Prince wrote:

>Part of the problem seems to be that flex has added features which
can't be supported fully without some posix environment....

My solution for that problem is a Linux box, where ./configure already
works, then compiling the configured sources under the actual target
system (Windows), with "native" tools. ...

Cygwin configures and builds current flex "out of the box," and I get
only 1 adverse indication in the testsuite. Your recommendation to
use linux amounts to using a posix environment, more so than
cygwin. So, I'm not convinced by any of these suggestions that
avoiding posix emulations makes it easier.

[Hans-Peter Diettrich]

tim prince wrote:

Cygwin configures and builds current flex "out of the box," and I get
only 1 adverse indication in the testsuite. Your recommendation to
use linux amounts to using a posix environment, more so than
cygwin. So, I'm not convinced by any of these suggestions that
avoiding posix emulations makes it easier.

Compiling to native code, for the actual target platform, eliminates
many problems in the later use of tools or libraries.

Like Wine for Linux, CygWin and MinGW are not *extensions* to the host
OS, they only open a *narrow* window into a different world. The use of
the output is restricted to the same emulator box.

With regards to autobloat, it's up to the author of the source code,
which target platform he wants to support. When he is a member of the
hate-Windows fraction, or simply doesn't care about non-POSIX platforms,
the configuration of his project will fail in CygWin, leaving the user
with uncompilable code. Autobloat is not only a tool set for making
projects platform independent, at the same time it allows to effectively
exclude platforms as well :-(

DoDi

[Thomas Dickey]

In comp.compilers George Neuner <gn******@comcast.netwrote:

I've successfully compiled past versions of both Flex and Bison using
Visual Studio (not the latest stuff though).

iirc, the "newest" stuff has a runtime dependency on m4.

I hadn't noticed the .34 release, but running a quick check, see that
not only have none of the bugs I reported some time ago been addressed, but
that this has some additional defect in the legacy tablesize options.

That means that it can't compile some files written for "older" lex's -
more than a quarter of the files I'm working with (ymmv). So don't
discard 2.5.4a - you'll continue to need it for a while.

We're talking about this -

http://flex.sourceforge.net/

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[Thomas Dickey]

In comp.compilers Hans-Peter Diettrich <Dr**********@aol.comwrote:

I don't think that a tool like flex really depends on special POSIX
features, apart from the file handling. More problems will result from

....a little more than that (2.5.4a only relies on file handling and is
very portable), the new (since 2002) version spawns a copy of m4 to
process some macros.

(coincidentally, I was looking at the .33 this morning, to see if it
addressed locales - 2.5.4a's rather limited) and found that aspect was not
improved in the newer version as well (lots of additional ifdef's, but
no new solutions). Perhaps someone will get interested in making flex's
parsing know about locales...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[Gary R. Van Sickle]

Cygwin configures and builds current flex "out of the box," and I get

only 1 adverse indication in the testsuite.

Unfortunately that's not entirely true. If you're using Cygwin's
"text mode mounts", current flex will compile fine, but the scanners
it generates are uncompilable, due to our old friend "The Inability Of
21st Century Computer Science To Solve The Clearly Intractable And
Apparently NP-Hard "\r\n" Vs. "\n" EOL Problem". For reasons I've
been unable to determine or correct, no matter what you do the
generated source has extra EOLs and "Pseudo-EOLs" (things like
"\r\r\n").

Your recommendation to
use linux amounts to using a posix environment, more so than
cygwin. So, I'm not convinced by any of these suggestions that
avoiding posix emulations makes it easier.

True enough, but step 1 is that it has to generate usable output.

[Tim Prince]

Gary R. Van Sickle wrote:

>Cygwin configures and builds current flex "out of the box," and I get
only 1 adverse indication in the testsuite.

Unfortunately that's not entirely true. If you're using Cygwin's
"text mode mounts", current flex will compile fine, but the scanners
it generates are uncompilable, due to our old friend "The Inability Of
21st Century Computer Science To Solve The Clearly Intractable And
Apparently NP-Hard "\r\n" Vs. "\n" EOL Problem". For reasons I've
been unable to determine or correct, no matter what you do the
generated source has extra EOLs and "Pseudo-EOLs" (things like
"\r\r\n").

>Your recommendation to use linux amounts to using a posix
environment, more so than cygwin. So, I'm not convinced by any of
these suggestions that avoiding posix emulations makes it easier.

True enough, but step 1 is that it has to generate usable output.

I'm not enough of a masochist to attempt Windows text mode. I haven't
heard of anyone but you telling us that anything but NotePad
compatible text in Windows is "cheating." Linux doesn't support this
kind of text mode; why should we make it impossibly difficult on
Windows?

[Hans-Peter Diettrich]

Gary R. Van Sickle wrote:

Apparently NP-Hard "\r\n" Vs. "\n" EOL Problem".

What's the problem?

AFAIK a single "\r" is nowhere used for EOL, so it should be possible to
skip \r, and treat \n as EOL.

DoDi
[That's pretty typical, ignore the \r and look for the \n. But this doesn't
have much to do with compilers, as opposed to general Windows programming,
any more. -John]

[Chris F Clark]

Hans-Peter Diettrich <Dr**********@aol.comwrites:

Gary R. Van Sickle wrote:

>Apparently NP-Hard "\r\n" Vs. "\n" EOL Problem".

What's the problem?

AFAIK a single "\r" is nowhere used for EOL, so it should be possible to
skip \r, and treat \n as EOL.

DoDi
[That's pretty typical, ignore the \r and look for the \n. But this doesn't
have much to do with compilers, as opposed to general Windows programming,
any more. -John]

Doesn't MacOS use a single \r to represent EOL rather than single \n?

However, the issue is more whether any given tool treats the
combinations of \r and \n characters in your file the way that you (or
some other tool you use) intended them to be treated (as a result I
have my own version of u2d and d2u that cannonicalizes them in the
ways that the tools I use accept them), so as our moderator said it
isn't much of a compiler question as a global question, with the
problem being that there is no universally accepted standard. Yes,
there are standards, but they aren't universally followed.

BTW, anyone who wants my copy of u2d/d2u and/or the Yacc++ grammar I
used in writing them, (Yes, I wrote a grammar to "parse" the problem.)
can get a free copy by writing me.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : co*****@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : [phone]
Berlin, MA 01503 USA fax : [phone] (24 hours)

[Richard Bos]

Chris F Clark <cf*@shell01.TheWorld.comwrote:

Hans-Peter Diettrich <Dr**********@aol.comwrites:

Gary R. Van Sickle wrote:

Apparently NP-Hard "\r\n" Vs. "\n" EOL Problem".

What's the problem?

AFAIK a single "\r" is nowhere used for EOL, so it should be possible to
skip \r, and treat \n as EOL.

DoDi
[That's pretty typical, ignore the \r and look for the \n. But this doesn't
have much to do with compilers, as opposed to general Windows programming,
any more. -John]

Doesn't MacOS use a single \r to represent EOL rather than single \n?

No. MacOS uses a single ASCII CR as EOL, while Unixen use LF and MS
OSes use CRLF. In a file opened as a text stream in C, though, all of
those will be represented in that text stream as '\n'. (And obviously,
they should also be represented as '\n' in any code-reading tool (as
opposed to, e.g., binary editors) written in ISO C.)

Richard

[Stefan Monnier]

Doesn't MacOS use a single \r to represent EOL rather than single \n?

It did. But Mac OS X switched to the Unix convention, so all is well.
Stefan
..