Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/18/2013 6:04 PM, Warren Young wrote:
> It would be possible, though somewhat evil, for Cygwin's exec()
> implementation to peek at the DLL dependency list of a program before
> starting it, and from that infer whether it should automatically
> translate paths.
>
> The I/O hit this would cause would be nontrivial.  Keep in mind that one
> of the core ideas behind Unix is that fork() is cheap, and exec() is
> even cheaper.  This deeply affects how software native to Unixy systems
> gets designed.  As a result, Cygwin already has a problem with its slow
> fork() implementation; this idea makes exec() expensive, too, with
> predictable consequences to overall system speed.
>
> I don't see how Cygwin couldn't afford to behave this way by default.
> Maybe as an option?

This is what MSYS-1 does. If the executable depends on the msys dll, 
then no path translation is done. If the executable does NOT depend on 
the msys dll, then path translation heuristics are employed. The speed 
hit of this check is relatively insignificant, all things considered. 
The biggest bugaboo is that "heuristic" == "a guess that is sometimes 
wrong".  MSYS handles things like scanning argv[] for stuff like 
-I/unixy/path and -L/unixy/path (also, I think, --some-opt=/unixy/path), 
in addition to standalong args that look like paths.

That stuff is slow...and often erroneous (e.g. in "dumpbin.exe 
/symbols", '/symbols' is an option, not a path...)  So there are 
workarounds:

bash-3.1$ dumpbin /symbols
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:/MinGW/msys/1.0/symbols
LINK : fatal error LNK1181: cannot open input file 
'C:/MinGW/msys/1.0/symbols'

Using multiple leading '/' disables path translation (*):
bash-3.1$ dumpbin //symbols
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


   Summary

(*) except that there are ADDITIONAL heuristics to determine if the 
argument is actually a UNC path, which SHOULD start with 2 / !!
http://www.mingw.org/wiki/Posix_path_conversion

This is not a simple task.

>>>> 2. Translating paths in arguments and environment variables to Windows
>
> I just re-read this, and realized the implications of "and environment
> variables."  You're proposing some kind of global search-and-replace
> operation, which will inevitably turn into a Whac-a-Mole game.
>
> (http://goo.gl/vpYfA)

Yes, yes it is. Welcome to MSYS.

>>   notepad /home/user/mydoc.txt
>
>  From my explanation above, you do see how expensive it would be for
> Cygwin to implement your desired behavior, right?
>
>> Also when you using autoconf utilities generated Makefile has Cygwin
>> paths and you cannot use it with native compiler.

> Those on the Automake list have wrestled with this off and on.  It's
> more or less impossible to solve, which is why competing systems like
> CMake, SCons and Bakefile were created.

And why msys's make.exe exists. It understands the "cygwin" paths in the 
Makefile, but when it launches (the native win32 "mingw" compiler) 
gcc.exe via the MSYS fork()/exec() codepath, all of the above heuristics 
come into play and (win32)gcc.exe gets all the wonderful X:/dos/style 
paths it likes.  OR so goes the idea.

> I think the best you can hope for is that if you run ./configure under
> Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that
> works with Cygwin make, which calls out to the MinGW cross-compiler.
> Since the cross-compiler is a Cygwin app, not a native executable, it
> understands POSIX paths yet still builds native Windows executables.
>
> Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed
> answer to your point #1.
>
>>>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>>>> DLL.

> What's wrong with using the MinGW cross-compiler from the Cygwin package
> repository instead?

Not all packages are cross-compiler-compatible. Arguably and ideally, 
THAT is what should be fixed, but we don't live in an ideal world.

> Here's something for you to try on your own system:
>
>      $ cd /bin
>      $ mv ln.exe sane-ln.exe
>      $ ln -s cp.exe ln.exe
>
> Or if you're feeling really ambitious, do it at the cygwin1.dll level,
> by changing its implementations of link(2) and symlink(2) to recursive
> copy operations.  You have the source.

This is what MSYS-1 does.

> If the resulting system works well at all, it will be much slower.

It is.

--
Chuck




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