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 14/02/2013 8:12 AM, Earnie Boyd wrote:
On Thu, Feb 14, 2013 at 5:02 AM, Corinna Vinschen wrote:
Another, more development oriented downside is the fact that we have to
introduce the cyg64 DLL prefix, which, as far as I remember from the
discussion in 2011, breaks libtool and potentially configury and/or
Makefiles of a couple of packages.
It would break every build system used to build libraries, as well as
programs which dlopen() prefixed libraries, of which there are many.
I assure you that it's a *very* big deal.
Sigh, yes, I noticed that already myself.  I didn't take that serious
two years ago since it sounded easy to fix.

My argument for cyg64 prefix was that there will be those that try to
do a mix and making it easily identifiable which DLL was actually
causing a problem.

Ok, so far we have three voices for keeping 32 and 64 bit separate,
one voice for mixing them, and one being very unsure.

Again, because people will do it.

Any more input?
Any way for the 64bit DLL to take a different code path for 32bit executables?
So, to get this straight, you're not so much proposing support for inter-op as you are advocating a clear separation between 32- and 64-bit versions to help people "see" what's wrong when they try to mix the two inappropriately?

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'

[1] This assumes the user didn't clobber their 32-bit install with a 64-bit one, completely replacing a subset of dlls with a new set having the wrong bitness. Mixed 1.5/1.7 installations were never allowed AFAIK, so I don't think 32/64-bit mixes need be.

$0.02
Ryan


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