Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <419EFB39.8020005@x-ray.at> References: <419E499B DOT 4040007 AT mvista DOT com> <6 DOT 1 DOT 0 DOT 6 DOT 0 DOT 20041119143038 DOT 04e7a008 AT pop DOT prospeed DOT net> <419E52C1 DOT 6030604 AT mvista DOT com> <419E5922 DOT 9060501 AT mvista DOT com> <419EFB39 DOT 8020005 AT x-ray DOT at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <29A01F5A-3B11-11D9-84CE-000D932D0448@rehley.net> From: Peter Rehley Subject: Re: flex and dos source files. How is flex built for cygwin Date: Sat, 20 Nov 2004 08:28:08 -0800 To: Cygwin List X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id iAKGT2x5027421 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/