flex and dos source files. How is flex built for cygwin

Peter Rehley peter@rehley.net
Sat Nov 20 16:28:00 GMT 2004


On Nov 20, 2004, at 12:07 AM, Reini Urban wrote:

> Peter Rehley schrieb:
>> Peter Rehley wrote:
>>> Larry Hall wrote:
>>>>> We have a customer that is using flex under a custom version of 
>>>>> cygwin that we provided them (with source).  The customer is 
>>>>> having problems when their "*.l" files are in dos format.  Flex is 
>>>>> taking the lines from the file and adding them into the lex.yy.c 
>>>>> file untouched.  (i.e. they still have the \n\r at the end), and 
>>>>> this causing problems later on.
>>>>>
>>>>> I tried using the version of flex that comes with the latest 
>>>>> version of cygwin (1.5.12) and flex changes the \n\r to just \n, 
>>>>> which makes everything work fine.  Good I thought since the 
>>>>> version of flex we provide is not the latest.  I'll just 
>>>>> recompile.
>>>>>
>>>>> But when I tried that with the latest flex (2.5.4a-3) I get the 
>>>>> same behavior that the customer is seeing.  I get this behavior 
>>>>> even if I compile on the latest version of cygwin.
>>>>>
>>>>> So, my question is what options are used for building flex?
>
> there's no build script and an inactive maintainer. we don't know. 
> hopefully just the standard options.
> ./configure --prefix=/usr sharedstatedir=/var --mandir=/usr/share/man
> make && make install

Using these options the behavior of flex differs from the flex that is 
shipped with cygwin.

>
>>>> Linking against /usr/lib/binmode.o perhaps?
>
> He meant that by accident flex was linked against binmode.o, which is 
> wrong. It was no advice to reproduce that error with linking against 
> binmode or textmount.
>
>>> Tried on cygwin 1.5.12
>>> make clean
>>> make LDFLAGS="/usr/lib/binmode.o",
>>>
>>> and
>>> make clean
>>> make LDFLAGS="-lbinmode"
>>>
>>> but neither helped
>
> for sure not.
>
>> However linking the /usr/lib/textmode.o did work
>> make LDFLAGS="/usr/lib/textmode.o" # <- did the job
>> Thanks Larry for pointing me in the right directory :)
>
> Oh god. This was the right direction? Sorry no.
>
> If you open your flex input file in a *textmode mount* \r\n will get 
> converted, if you open that in a binmode mount it will not get 
> converted.
> $ man mount
The filesystem has been mounted in binmode, but  the flex that comes 
with cygwin translates the files.  Both flex and the text file are on 
binmode mounts.

>
> So it's entirely a user problem behind the keyboard, and does NOT need 
> a changed linker line. Just tell the user to set this mount to 
> textmode, so that his DOSEOL will get converted. Or convert the DOSEOL 
> by basic commands like unix2dos.
Yes, there are things that the user can do to work around the problem, 
like saving the file as a unix file, and he is already using dos2unix.  
However when  I was doing research on this problem I found that the 
flex that comes with a standard cygwin distribution does the \r\n to \n 
translation when the directory is mounted in binmode.

When I compile flex, it doesn't do the translation.  If the flex that 
came with cygwin didn't do the translation, there would be no 
questions, but since it does something different, I wanted to know how 
it was compiled because it was obviously compiled differently.  Larry 
offered a suggestion that led me to the solution that flex had been 
linked with /usr/lib/textmode.o, because when I use that option I get 
the same behavior that I see with the flex shipped with cygwin.

It could be that the maintainer of flex used /usr/bin/textmode.o to 
ensure that dos files wouldn't cause problems.

>
> But if you force linking against binmode or textmode, your flex binary 
> will do no conversions at all, and will only work on the matching 
> mount modes.
If I understand right, then a program linked with textmode won't do a 
translation in binmode? but this is not the behavior that I'm seeing
>
> This is a pretty basic cygwin FAQ, and I wonder why this needs such a 
> long and wrong consideration.
Just trying to figure why the flex packaged with cygwin behaves 
differently than one compiled on the system.
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>
>
Enjoy,
Peter
-------------------------------
A Møøse once bit my sister


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list