MSYS mode (continue)

Fri Jul 26 15:48:00 GMT 2013

Hash: SHA1

On 26.07.2013 19:14, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote:
>> On Jul 25 16:53, Christopher Faylor wrote:
>>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>>> But underlying there's still a normal Cygwin DLL and
>>>>> most tools could just be copied verbatim since they don't need this
>>>>> extra functionality.
>>>> And that's the bit where I disagree.  Sure, some scripting tools might 
>>>> not need adjustment, so long as their interpreter was $MSYS-enabled 
>>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
>>>> dos-style paths, so its interpreter better be able to handle them.
>>>> But unless you restrict yourself to only passing around relative paths 
>>>> (or god forbid, that old "unity mount" idea), any .exe will need to live 
>>>> in one world or the other. Otherwise, how would paths be interpreted? 
>>>> Using which tools' mount table?
>>>> Naturally from the command line I can compensate:
>>>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
>>>> -d /msys/mount/table/path) )
>>>> but yee gods that'd be annoying in any automated setting.
>>> I don't know if this helps but the vague plan is to now have two DLLs
>>> where before you only had one.  You'd still be providing "MSYS" binaries
>>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>> You'd still have a normal MSYS distribution and it would still, in theory,
>>> support everything (with the possible exception of very lax security) that
>>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>>> bash, etc.
>> Here's where I disagree.  I think the executables should *not* rely on
>> MSYS.dll being available.  Ideally the executables are linked against
>> the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
>> So, if MSYS.dll isn't available, they still function as normal Cygwin
>> executables.  That's why I proposed the solution(s) in
>> Assuming you implement it the first way, you get an executable linked
>> against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
>> the executable does business as usual.  It will not fail, because
>> there's still the Cygwin DLL.
>> If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
>> __msys_hook().  __msys_hook collects the hook function pointers and
>> sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
>> &hook_list).  Voila, the hooks are set up, we're in MSYS mode.
>> Another alternative would be if the Cygwin DLL itself had a switch to
>> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
>> even with completely unchanged executables.
>>> I don't think anyone was proposing seamless interoperation between MSYS
>>> and cygwin.
>> Yes, I honestly think this would be possible and desirable.  MSYS is
>> just a tiny change for a specific task in comparison to the default
>> Cygwin mode.  MSYS would concentrate on this task and the required tools
>> for this task and the rest could be stock Cygwin distro.
>> Btw., this does *not* mean I agree with all changes MSYS is doing.  I
>> have a hard time to see the necessity changing the /etc/fstab layout,
>> for instance, since it doesn't add or change anything you can't have
>> with the standard fstab.
> So, you did.  I missed the ramifications of that message.  I guess
> that's why Chuck was confused.  I'm suggesting something different so
> we're all confused.
> This does not address the problem that there are local modifications in
> some MSYS utilities.  This doesn't solve the problem of make
> understanding c:\foo.
Yep, you need make sure that make is not configured with ac_cv_dos_paths=no.

>  Doesn't MSYS bash allow constructs of the form
> c:\foo without making that c:foo?
It doesn't. You have to carefully avoid the use of '\' everywhere (much
easier than escaping it).

> I don't think that we should be seeing the word "msys" throughout the
> DLL source code.  The hooks could all be just named "cygwin_hook"
> generic and, maybe we should recognize something like a
> "CYGWIN=PRELOAD=MSYS.dll".  I don't know how the MSYS folks would
> feel about that however.  Having to tell their users that they need
> to set an environment variable before they do anything seems like it
> would be a maintenance headache.
MSYS actually does require an environment variable to be set.
MSYSTEM=MINGW32 or MSYSTEM=MSYS (at least MSYS1 did, if you wanted to
use it with MinGW, and MSYS2 does, in its current form). Most users must
have MSYSTEM=MINGW32, otherwise their build system type will be
misdetected (as MSYSTEM affects the name returned by uname() syscall).

In MSYS1 this was done by the msys.bat batch file that was used to
launch the shell.

> As far as /etc/fstab is concerned, since they were the first to
> implement the notion, I would assume that they don't want to have to
> tell their userbase to change any more than we would want to have to
> tell every Cygwin user that they have to edit a file to make the
> next version of Cygwin work correctly.

I wouldn't worry about this too much. MSYS2, being nearly pure Cygwin,
may require more elaborate installation procedures than MSYS1 did. These
procedures could include an /etc/fstab conversion script, if users
upgrade from MSYS1.

MSYS1 compatibility might be interesting for some people (for
- - definitely), but not for everyone.

- -- 
O< ascii ribbon - stop html email! -
Version: GnuPG v1.4.11 (MingW32)


More information about the Cygwin-developers mailing list