RFC: Cygwin 64 bit?

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Jun 28 20:14:00 GMT 2011

On 6/28/2011 4:00 PM, Brendan Conoboy wrote:
> On 06/28/2011 12:51 PM, Yaakov (Cygwin/X) wrote:
>> Can *someone* tell me why this is absolutely necessary?  I have yet to
>> hear a single reason that wouldn't be solved by supporting parallel
>> installations like we did with 1.5-to-1.7.

Well, given that we *can't* have a (64bit) foo.exe until all of its DLLs
have been ported to 64bit, I guess there's less worry about a partially
functioning tree than I had thought.  It *will* be partially functioning
until a large number of DLLs are ported, before many apps are available
at all.

When in turn means that you'll need to keep a "working" 32bit
installation usable anyway for quite some time.  What that tells me is,
even IF we supported a single-tree cyg64/32 deployment, I'd still have
to have a "pure" 32bit co-installed tree somewhere else on my system.

> Also, in 5 years when nobody is running 32 bit windows, will everybody
> still be happy with all these 64s in their paths and filenames?

How many Fedora or RHE customers complain about /lib64?

> Coinstalled trees make sense to me, c;\cygwin and c:\cygwin64 for
> example.  And while assumptions are being challenged, do DLLs really
> need to have a cyg prefix?

The cyg prefix has protected us from "corruption" by native (mingw32 or
msvc-compiled) DLLs that use the "lib" prefix.  Many "native" tools have
no compunction about inserting their installation path in the front of
$PATH (hello, GIMP, I'm looking at you).  Since they include a
libintl-N.dll and many other DLLs that have identical names to the
cgywin ones (modulo the prefix), this would cause any cygwin app NOT
installed in /bin to die mysteriously.

If we take one of the suggestions elsewhere in this thread, and move
cgywin DLLs into /lib and rely on solely on $PATH rather than
$dir-of-EXE to find most DLLs, the problem gets even worse: /bin/bash
would load the wrong libintl-8.dll and would coredump, before getting a
chance to run .bash_profile to set the $PATH "properly".

As much as Yaakov complains about the cyg prefix, it solves a lot more
problems than it creates, especially of the newbie
brand-new-installation-fails-to-work variety.


More information about the Cygwin-developers mailing list