This is the mail archive of the cygwin-developers 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: Resurrect discussion: Mixing 32 and 64 bit distro


On Feb 14 08:59, Ryan Johnson wrote:
> Doesn't the windows loader completely ignore DLLs having the wrong
> bit-ness? If so, the only problem from mixing them would be failure
> to load dlls that you think are available [1]. Rather than changing
> the prefixes and breaking any number of tools, couldn't we just
> modify ldd/cygcheck to check (if they don't already)? Then,
> identifying the problematic dll(s) would be pretty easy, even if the
> user doesn't want to use 'file' or 'objdump'

I just read that again and realized that it's a question.  Yaakov
tested this assumption back in 2011.  Yes, if two DLLs using the
same name but for a different platform are in the DLL search path,
the Windows loader loads the right one for the given executable's
platform.

So we have five voices for keeping 64 and 32 bit separate, one for
mixing, one undecided but now leaning towards keeping it separate.  I
also asked two people off-list, and both of them thought it a good idea
to keep the distros separate.

I'm inclined to revert or tweak a couple of my patches which were meant
to mix the distros.  My implied question to you for each of these points
is, shall I do that or not?

1. Revert all toolchain changes which change the DLL prefix from
   "cyg" to "cyg64".  

   This is apparently the right thing to do if we want to be able
   to build 64 bit packages without having to change libtool etc.

2. Rename the Cygwin DLL back from cyg64win1.dll to cygwin1.dll.

   This is probably purely a matter of taste.  It has nothing to do with
   point 1.  We can keep the name of theCygwin DLL without compromising
   the "cyg" prefix elsewhere.  Actually, it even simplifies the
   recognition of a 64 bit Cygwin process at spawn/exec time.

3. Revert the path to link libs from "${prefix}/lib64" to "${prefix}/lib".

   I'm actually not quite sure about that.  The lib64 path is in the
   toolchain now and it appears to work nicely.  Apparently it also
   works fine for 64 bit Linux.  In conjunction with point 1, if we
   ever decide that we yet need interoperability with 32 bit Cygwin
   processes, keeping the lib path to lib64 would help to integrate
   both worlds.  What is the problem with lib64 again?


Thanks for your input,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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