This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
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.
--
Chuck