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:
> 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

My 2ct here: On 64 bit Linux, the 64 and 32 bit .so files have the same
name as well.  If a user *seriously* thinks it's a good idea to copy a
.so file from /lib to /lib64, thus overwriting the 64 bit .so, he
deserves to suffer.

Along the same lines you could think of a user copying a cygfoo.dll to
cyg64foo.dll since that obviously changes the DLL from 32 to 64 bit.

Ultimately there's nothing you can do against cluelessness.


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]