RE: sed: 4.1.5 breaks libtool generation
By Gawk! You're right! Sed "broke" one on my little scripts, but there is an easy work around. It isn't really sed so much as white space confusion. -Original Message- From: Igor Peshansky [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 11:47 AM To: Stepp, Charles Cc: cygwin@cygwin.com Subject: RE: sed: 4.1.5 breaks libtool generation <http://cygwin.com/acronyms/#TOFU> reformatted. On Wed, 21 Jun 2006, Stepp, Charles wrote: > -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 17, 2006 12:30 AM > To: [EMAIL PROTECTED] <http://cygwin.com/acronyms/#PCYMTNQREAIYR>. Thanks. > Subject: Re: sed: 4.1.5 breaks libtool generation > > > On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote: > > >Given the fact that cygwin runs on a machine where the native linend > > >is CRLF, having a major component not recognise CRLF as a linend when > > >handling text files is, AFAIAC, a major problem. > > > > ...unless you stop to consider that sed is supposed to work correctly > > on binary files. > > > > cgf > > It is? Yes. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/
RE: sed: 4.1.5 breaks libtool generation
<http://cygwin.com/acronyms/#TOFU> reformatted. On Wed, 21 Jun 2006, Stepp, Charles wrote: > -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 17, 2006 12:30 AM > To: [EMAIL PROTECTED] <http://cygwin.com/acronyms/#PCYMTNQREAIYR>. Thanks. > Subject: Re: sed: 4.1.5 breaks libtool generation > > > On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote: > > >Given the fact that cygwin runs on a machine where the native linend > > >is CRLF, having a major component not recognise CRLF as a linend when > > >handling text files is, AFAIAC, a major problem. > > > > ...unless you stop to consider that sed is supposed to work correctly > > on binary files. > > > > cgf > > It is? Yes. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/
RE: sed: 4.1.5 breaks libtool generation
It is? -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 12:30 AM To: cygwin@cygwin.com Subject: Re: sed: 4.1.5 breaks libtool generation On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote: >Given the fact that cygwin runs on a machine where the native linend is >CRLF, having a major component not recognise CRLF as a linend when >handling text files is, AFAIAC, a major problem. ...unless you stop to consider that sed is supposed to work correctly on binary files. cgf -- 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/
Re: sed: 4.1.5 breaks libtool generation
Just sending the OPs reply so that it is in the mailing list archive. Mark Hessling wrote: Mark Hessling wrote: Actually, what you describe is clear enough, but since CRLF handling isn't done by the Linux version of sed either, you would have the same problem on Linux. The question here is how did this file get created with CRLF in the first place? I have several cross-platform projects managed in a CVS repository. Several of them are built with different Win32 compilers on the same Windows XP machine. So my direcory tree looks something like: projects Regina vc bcc cygwin Given the fact that cygwin runs on a machine where the native linend is CRLF, having a major component not recognise CRLF as a linend when handling text files is, AFAIAC, a major problem. Given that you know all the files in this tree are CRLF terminated, is it appropriate to mount this directory in text mode? Does the configure work if this is done? Yes it does. Thanks. I wasn't aware of mount features; I've just been using the default mounts; d: -> /cygdrive/d, etc. which are in binary mode. Cheers, Mark. -- 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/
Re: sed: 4.1.5 breaks libtool generation
Mark Hessling wrote: Actually, what you describe is clear enough, but since CRLF handling isn't done by the Linux version of sed either, you would have the same problem on Linux. The question here is how did this file get created with CRLF in the first place? I have several cross-platform projects managed in a CVS repository. Several of them are built with different Win32 compilers on the same Windows XP machine. So my direcory tree looks something like: projects Regina vc bcc cygwin Given the fact that cygwin runs on a machine where the native linend is CRLF, having a major component not recognise CRLF as a linend when handling text files is, AFAIAC, a major problem. Given that you know all the files in this tree are CRLF terminated, is it appropriate to mount this directory in text mode? Does the configure work if this is done? Dave. -- 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/
Re: sed: 4.1.5 breaks libtool generation
Original message >Date: Sat, 17 Jun 2006 00:30:05 -0400 >From: Christopher Faylor <[EMAIL PROTECTED]> >Subject: Re: sed: 4.1.5 breaks libtool generation >To: cygwin@cygwin.com > >On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote: >>Given the fact that cygwin runs on a machine where the native linend is >>CRLF, having a major component not recognise CRLF as a linend when >>handling text files is, AFAIAC, a major problem. > >...unless you stop to consider that sed is supposed to work correctly on >binary files. That is a valid point, but what is more common; sed using text or binary files? Cheers, Mark > >cgf > >-- >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/ > -- Mark Hessling http://www.rexx.org/ Author of THE, Rexx/SQL, Rexx/cURL, Rexx/DW, Rexx/curses, etc.. Project Manager of ooRexx Maintainer of Regina Use Rexx ? Join the Rexx Language Association: http://www.rexxla.org/ Google Earth: 27d43'43.10"S,153d02'20.03"E -- 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/
Re: sed: 4.1.5 breaks libtool generation
On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote: >Given the fact that cygwin runs on a machine where the native linend is >CRLF, having a major component not recognise CRLF as a linend when >handling text files is, AFAIAC, a major problem. ...unless you stop to consider that sed is supposed to work correctly on binary files. cgf -- 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/
Re: sed: 4.1.5 breaks libtool generation
I've just found the above titled thread; the problem I am also encountering. >Actually, what you describe is clear enough, but since CRLF handling >isn't done by the Linux version of sed either, you would have the same >problem on Linux. The question here is how did this file get created >with CRLF in the first place? In my case, which I wouldn't think is not that unusual is as follows. I have several cross-platform projects managed in a CVS repository. Several of them are built with different Win32 compilers on the same Windows XP machine. So my direcory tree looks something like: projects Regina vc bcc cygwin The indents are to represent subdirectories. ie projects/Regina/vc, projects/Regina/cygwin, etc. All the source is in projects/Regina in DOS CRLF format; that's the way CVS retrieves it from the repository. To build Regina with cygwin, I "cd projects/Regina/cygwin" and run "../configure". With sed 4.1.5, config.h and other files that are generated by the configure script are not updated properly, due to the fact that CRLF does not terminate the lines in the respective input files. So each time I build Regina under cygwin, I have to convert each of the *.in files to LF linends. Then I have to remember to convert them back to CRLF in case I change them and check them back into CVS. With sed 4.1.4 CRLF as an end of line was recognised correctly. Given the fact that cygwin runs on a machine where the native linend is CRLF, having a major component not recognise CRLF as a linend when handling text files is, AFAIAC, a major problem. Cheers, Mark -- Mark Hessling http://www.rexx.org/ Author of THE, Rexx/SQL, Rexx/cURL, Rexx/DW, Rexx/curses, etc.. Project Manager of ooRexx Maintainer of Regina Use Rexx ? Join the Rexx Language Association: http://www.rexxla.org/ Google Earth: 27d43'43.10"S,153d02'20.03"E -- 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/
Re: sed: 4.1.5 breaks libtool generation
Corinna Vinschen writes: > Actually, what you describe is clear enough, but since CRLF handling > isn't done by the Linux version of sed either, you would have the same > problem on Linux. Sure, no argument here. My goal wasn't to prove that Cygwin's sed is doing something wrong, but rather to confirm that the strange behaviour of the new version of sed, encountered by some, is due to improper form of line ends, thus the fault is on the user's, not tool's, side. > The question here is how did this file get created with CRLF in the > first place? It's actually easy -- one just needs to use a Windows editor that's unaware of alternative forms of line ends and quietly saves the file with CRLFs. > However, I have a bit of a problem here, either files are read with CRLF > conversion, as up to 4.1.4. In that case you can't use sed on binary > files. Or sed does not do CRLF conversion as on any other OS. Then you > get trouble with plain DOS files. However, this latter problem can be > solved by using a filter like dos2unix before feeding the input to sed, > while the first problem can never be solved if sed always makes a CRLF > conversion. If it were my decision, I'd go for the non-converting version, as is now, even though it means that some users will be required to break certain habits. After all, Cygwin emulates Linux, so it figures that the same behaviour of tools should be expected. I, for one, learned my lesson, dos2unix'ed all files that are to be processed by any of the Cygwin's tools and decided to (when in Windows) only use those editors that respect the appropriate form of line ends. By the way, kudos to you all gals and guys who keep this respectable machinery running and evolving. Best regards. -- 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/
Re: sed: 4.1.5 breaks libtool generation
On Feb 25 04:19, Wlodek Szafran wrote: > Corinna Vinschen cygwin.com> writes: > > > sed's internal getline enforces CRLF line ending recognition regardless > > of the mount type, which results in mishandling of binary input files. > > sed has no -b/--binary option. So by using newlib's getline which > > doesn't enforce CRLF->LF conversion, sed 4.1.5 should be actually > > "fixed", FWIW. If you need CRLF->LF conversion, you can use a filter > > application like dos2unix. > > > > Nothing's impossible, but I'd be actually surprised if that's the cause > > for the libtool misbehaviour. > > It seems to be the true reason, though. I've noticed this strange behaviour > with one of configure scripts I'm using. The script uses sed to edit a file > which consists of description/value pairs and before version 4.1.5 there were > no > problems. After updating sed to this version, I've noted that the contents of > the mentioned file were left unedited after the script ran, which was puzzling > until reading here about the line endings. A simple experiment shows that if > the input file has CRLF line endings, no replacements of text happen -- the > output file seems to be just a copy of the input one. However, after the > input > file was converted to LF line endings, everything went back to normal. Actually, what you describe is clear enough, but since CRLF handling isn't done by the Linux version of sed either, you would have the same problem on Linux. The question here is how did this file get created with CRLF in the first place? However, I have a bit of a problem here, either files are read with CRLF conversion, as up to 4.1.4. In that case you can't use sed on binary files. Or sed does not do CRLF conversion as on any other OS. Then you get trouble with plain DOS files. However, this latter problem can be solved by using a filter like dos2unix before feeding the input to sed, while the first problem can never be solved if sed always makes a CRLF conversion. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: sed: 4.1.5 breaks libtool generation
Corinna Vinschen cygwin.com> writes: > sed's internal getline enforces CRLF line ending recognition regardless > of the mount type, which results in mishandling of binary input files. > sed has no -b/--binary option. So by using newlib's getline which > doesn't enforce CRLF->LF conversion, sed 4.1.5 should be actually > "fixed", FWIW. If you need CRLF->LF conversion, you can use a filter > application like dos2unix. > > Nothing's impossible, but I'd be actually surprised if that's the cause > for the libtool misbehaviour. It seems to be the true reason, though. I've noticed this strange behaviour with one of configure scripts I'm using. The script uses sed to edit a file which consists of description/value pairs and before version 4.1.5 there were no problems. After updating sed to this version, I've noted that the contents of the mentioned file were left unedited after the script ran, which was puzzling until reading here about the line endings. A simple experiment shows that if the input file has CRLF line endings, no replacements of text happen -- the output file seems to be just a copy of the input one. However, after the input file was converted to LF line endings, everything went back to normal. Best regards. -- 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/
Re: sed: 4.1.5 breaks libtool generation
On Feb 24 12:08, Pavel Holejsovsky wrote: > Corinna Vinschen wrote: > >On Feb 24 04:01, Charles Wilson wrote: > >>Yaakov S (Cygwin Ports) wrote: > >>>-BEGIN PGP SIGNED MESSAGE- > >>>Hash: SHA1 > >>> > >>>After a recent update to my Cygwin installation, suddenly > >>>configure-generated libtool scripts give me this error when compiling > >>>and linking C++ code: > >>> > >>>libtool: ignoring unknown tag CXX > >>> > >>>And even worse, it tries to use gcc to link, which of course fails > >>>because of undefined symbols provided by libstdc++. > >>> > >>>Using the /usr/bin/libtool instead works, so this would seem to be > >>>caused during the generation of the package libtool. > >>> > >>>So I guessed that the sed update was the problem, and I was right. > >>>Downgrading sed to 4.1.4-1 makes everything work again. > >>> > >>>I'm attaching my cygcheck output (before I downgraded sed). > >>> > >>Thanks for the heads up. I'll try to look in to it, but it might be a > >>week or two. > > > >I would appreciate any hint here. sed 4.1.5-1 has 0 FAILs in the sed > >testsuite and the only really interesting Cygwin related difference > >between 4.1.4 and 4.1.5 is that 4.1.4 uses sed's own implementation > >of getline(), while 4.1.5 uses the newlib version of getline. > > One incompatibility of 4.1.5 is that sed no longer works correctly with > CRLF-style files on binary mounts. For example, 's/^$//' script no > longer filters out empty lines if they are CRLF terminated, but works OK > for LF terminated lines. However, I'm not sure whether this causes the > problem described above. sed's internal getline enforces CRLF line ending recognition regardless of the mount type, which results in mishandling of binary input files. sed has no -b/--binary option. So by using newlib's getline which doesn't enforce CRLF->LF conversion, sed 4.1.5 should be actually "fixed", FWIW. If you need CRLF->LF conversion, you can use a filter application like dos2unix. Nothing's impossible, but I'd be actually surprised if that's the cause for the libtool misbehaviour. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: sed: 4.1.5 breaks libtool generation
Pavel Holejsovsky wrote: One incompatibility of 4.1.5 is that sed no longer works correctly with CRLF-style files on binary mounts. For example, 's/^$//' script no longer filters out empty lines if they are CRLF terminated, but works OK for LF terminated lines. However, I'm not sure whether this causes the problem described above. I'm sorry, my example script was of course wrong, correct one to demonstrate the problem is e.g. '/^$/d' Pavel -- 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/
Re: sed: 4.1.5 breaks libtool generation
Corinna Vinschen wrote: On Feb 24 04:01, Charles Wilson wrote: Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a recent update to my Cygwin installation, suddenly configure-generated libtool scripts give me this error when compiling and linking C++ code: libtool: ignoring unknown tag CXX And even worse, it tries to use gcc to link, which of course fails because of undefined symbols provided by libstdc++. Using the /usr/bin/libtool instead works, so this would seem to be caused during the generation of the package libtool. So I guessed that the sed update was the problem, and I was right. Downgrading sed to 4.1.4-1 makes everything work again. I'm attaching my cygcheck output (before I downgraded sed). Thanks for the heads up. I'll try to look in to it, but it might be a week or two. I would appreciate any hint here. sed 4.1.5-1 has 0 FAILs in the sed testsuite and the only really interesting Cygwin related difference between 4.1.4 and 4.1.5 is that 4.1.4 uses sed's own implementation of getline(), while 4.1.5 uses the newlib version of getline. One incompatibility of 4.1.5 is that sed no longer works correctly with CRLF-style files on binary mounts. For example, 's/^$//' script no longer filters out empty lines if they are CRLF terminated, but works OK for LF terminated lines. However, I'm not sure whether this causes the problem described above. Pavel -- 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/
Re: sed: 4.1.5 breaks libtool generation
On Feb 24 04:01, Charles Wilson wrote: > Yaakov S (Cygwin Ports) wrote: > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >After a recent update to my Cygwin installation, suddenly > >configure-generated libtool scripts give me this error when compiling > >and linking C++ code: > > > >libtool: ignoring unknown tag CXX > > > >And even worse, it tries to use gcc to link, which of course fails > >because of undefined symbols provided by libstdc++. > > > >Using the /usr/bin/libtool instead works, so this would seem to be > >caused during the generation of the package libtool. > > > >So I guessed that the sed update was the problem, and I was right. > >Downgrading sed to 4.1.4-1 makes everything work again. > > > >I'm attaching my cygcheck output (before I downgraded sed). > > > > Thanks for the heads up. I'll try to look in to it, but it might be a > week or two. I would appreciate any hint here. sed 4.1.5-1 has 0 FAILs in the sed testsuite and the only really interesting Cygwin related difference between 4.1.4 and 4.1.5 is that 4.1.4 uses sed's own implementation of getline(), while 4.1.5 uses the newlib version of getline. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: sed: 4.1.5 breaks libtool generation
Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a recent update to my Cygwin installation, suddenly configure-generated libtool scripts give me this error when compiling and linking C++ code: libtool: ignoring unknown tag CXX And even worse, it tries to use gcc to link, which of course fails because of undefined symbols provided by libstdc++. Using the /usr/bin/libtool instead works, so this would seem to be caused during the generation of the package libtool. So I guessed that the sed update was the problem, and I was right. Downgrading sed to 4.1.4-1 makes everything work again. I'm attaching my cygcheck output (before I downgraded sed). Thanks for the heads up. I'll try to look in to it, but it might be a week or two. -- Chuck -- 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/
