RFC: Cygwin 64 bit?
Tue Jun 28 21:45:00 GMT 2011
Am 28.06.2011 23:36, schrieb Ryan Johnson:
> On 28/06/2011 4:42 PM, Corinna Vinschen wrote:
>> On Jun 28 22:36, Thomas Wolff wrote:
>>> Corinna wrote:
>>>> The original idea to keep the DLLs in /bin was to allow running Cygwin
>>>> applications from a non-Cygwin process without hassle. A typical
>>>> example is CMD. You can simply chdir to C:\cygwin\bin and run
>>>> `ls'. If
>>>> /lib contains all the DLLs, this will break unless C:\cygwin\lib is in
>>>> Also, you can't just create a bash shortcut on the desktop, unless you
>>>> really know what you're doing (set the start directory in the shortcut
>>>> to C:\cygwin\lib). When moving the DLLs out of /bin, you add some new
>>>> hurdle to using Cygwin.
>>>> Without this problem, or if we decide to ignore this problem, I
>>>> would be
>>>> all for moving DLLs to /lib or /lib64.
>>> Can't cygwin compilation ensure that the cygwin1.dll is always
>>> loaded first so it could take care of this (if only by then adding
>>> to the path)?
>>> (I guess the answer may be no because Windows is juggling with the
>> Yes, the answer is no. At least it's very likely no. Even if Cygwin is
>> loaded first, I'm not aware that changing $PATH from within the DLL
>> entry point will influence the Windows loader for this very process.
>> Somehow this even sounds like a potential security problem. Otherwise,
>> for Cygwin distro DLLs it's pretty sure that the Cygwin DLL will be
>> loaded first, since every subsequent DLL depends on it.
> The answer is definitely "no." Windows can map dlls in any order it
> pleases, and is only semi-required to initialize them in dependency
> order (because dlls are often circular dependent anyway). In
> particular, dlls which suffer base address collisions tend to be
> loaded before cygwin1.dll
Last feable attempt: So why does cygwin have to let Windows load the
DLLs at all? Couldn't the programs just have a stub that uses a
dedicated version of dlopen for dynamic linking?
More information about the Cygwin-developers