This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding MSYS functionality to Cygwin

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.


(*) except that there are ADDITIONAL heuristics to determine if the argument is actually a UNC path, which SHOULD start with 2 / !!

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.


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

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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]