Re: Patches for Mingw/MSYS

[heromyth]

Bob Friesenhahn wrote:
> On Thu, 16 Jun 2005, Peter Ekberg wrote:
>
> > I'm curious, how did you get "*-*-msys*" into $host? I thought MSYS
> > was autodetected as *-*-mingw* by config.guess. Is that not always
> > the case?
>
>
> Same wonderings here.  Unless someone has changed the operation of 
> standard config.guess.
>
> > (But I do believe that MSYS is a better basis for a name for $host
> > than MinGW, since I have understood it as MSYS being the
> > environment and MinGW the compiler/toolchain. But that's a bit
> > late to change IMHO.)

In fact, there are two development environment in MSYS Tools of Mingw.
One is MINGW, and another is MSYS. Some programs like RXVT just can be
developed in the MSYS enviroment, so what we need is not only the MINGW
enviroment. The MSYS enviroment is equal to the CYGWIN enviroment, just
the name and version are unequal. The programs developed in MSYS
enviroment are POSIX ones, and the programs developed in MINGW
enviroment are WIN32 ones. I think everybody has known it. This patch
 must not to do for everyone. Of course, only patch ltmain.sh is not 
enough.


> > Regarding the suggestion to remove .exe from cwrapper, that can't
> > be 100% right as $RM $cwrapper on the line following your change
> > will then not remove the exe-file (as intended?).
>
>
> Cygwin and MSYS both use a .exe-based wrapper, which is different than 
> for Unix platforms (even though Unix could use it).  I am not sure why 
> the extension should be removed.  It seems like that would break 
> something since the bare name without the extension is the formal target 
> name.

This patch should be done, I think, maybe before more tests have done.
There are tow EXE file, if there is no this patch. One is real EXE file
existed in subdirctory .libs, and another is just a shell script file
which EXTname is EXE and just can be run in Shell(I think the EXE is
redundant ).

During the tests of automake CVS, I make a test running this:
        VERBOSE=yes make check TESTS="nobase.test"
If no this patch, this test can't pass. After failed, I run this cmd:
        ./libtool --tag=CC   --mode=link gcc  -g -O2   -o sub/base.exe source.o

in testSubDir, and I get a file named base(notice no .exe) in
testSubDir/sub and another file named base.exe in testSubDir/sub/.libs.

Now I run the same command again. This time I also get two file: both
are named base.exe. The one in testSubDir/sub is still just a script
file. The original base disappears.

And run the command again. The result is same to the first running.

And run again, the result is same to the second running.

And run again, the result just repeat the first tow runnings.
        ............

If I patch it, this phenomena disappears. Just get base in
testSubDir/sub and base.exe in testSubDir/sub/.libs