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 13:30, Алексей Павлов wrote:
2013/6/18 Warren Young <>:
On 6/18/2013 12:40, Алексей Павлов wrote:

1. The correct definition of executables belonging to Cygwin DLL.

Can you give an example of what you mean here?

All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.

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?

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.


  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.

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

Who needs this, and why?

To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.

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

5. Use shorted mount point options in /etc/fstab - only win32_path and

Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.

I don't see why that's Cygwin's concern.

It should be sufficient for Cygwin to provides a reasonable path forward, so that those relying on MSYS can migrate to the new scheme.

Infinite backwards compatibility is its own problem.

Doesn't it conflict with your point #3?  A portable Cygwin would go out of
its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
would simply provide an unchangeable default behavior, and you'd have to be
happy with it.

No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)

If you need custom mount points and such, use Cygwin.

For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.

I already know that. Your proposal is wrong-headed from the start. If you repeat it, it's still incorrect.

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.

If the resulting system works well at all, it will be much slower. I predict you'll find that something breaks, though, due to the semantic issues I tried to show by example in my previous post.

Problem reports:
Unsubscribe info:

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