Re: Line endings on Windows with libtool.m4

[Tom Bramer]

Hello Peter,

You are correct about using a native Win32 version of GCC under Cygwin.  
It is not built specifically as a cross compiler for use in Cygwin, 
though the name of the executable is misleading (I renamed it in order 
to be able to discern it from another version of GCC, in it's original 
name, mingw32-g++).  The difference in line ending handling between MSYS 
bash and Cygwin bash hadn't even occurred to me at the time I submitted 
this, especially since the setup has been working for quite some time.

I generated libtool by running configure with MSYS bash, and the output 
appears to be correct without needing to strip '\015' from the end of 
the linker output (the full path to crtend.o was detected correctly and 
the shared libraries were usable).
So I wouldn't think that this would be considered a bug (at least to a 
reasonable extent), just a bit of an inconvenience.
Thank you for your help and keep up the good work.

Best Regards,
-- Tom

Peter Rosin wrote:
> Den 2008-09-04 04:13, skrev Tom Bramer:
> > Hello,
> >
> > I found an issue which I believe to be a bug, relating to line 
> > endings on Windows (like there hasn't been anything like this 
> > before).  Some likely to be important details about the environment 
> > include:
> >
> > OS: Windows XP
> > Script host: Cygwin (Bash 3.2.39(20))
> > Compiler toolchain: GCC 4.3.2 (unofficial mingw32 build as can be 
> > found at http://www.tdragon.net/recentgcc/).
> > Libtool version: 1.5.27a-1 (perhaps a Cygwin patched version?).
> > Autoconf version: 2.61
>
> *snip*
>
> Hi Tom,
>
> I smell a problem here, Cygwin isn't primarily for running native windows
> applications, it's primarily for running Cygwin apps. Whenever you try to
> cross that boundary, you inevitably end up with these warts. And I get 
> the
> feeling that your gcc is just such a native windows application, and not
> a MinGW targeting cross compiler for the Cygwin host. I haven't double
> checked that of course, but if that's indeed the case you might have more
> luck with MSYS as the script host instead.
>
> Cheers,
> Peter