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 15 11:57, Andy Koppe wrote:
> On 15 February 2013 11:40, Corinna Vinschen wrote:
> > On Feb 15 04:40, Yaakov wrote:
> >> On Fri, 15 Feb 2013 11:22:26 +0100, Corinna Vinschen wrote:
> >> > 1. Revert all toolchain changes which change the DLL prefix from
> >> >    "cyg" to "cyg64".
> >>
> >> Revert.
> >>
> >> > 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.
> >>
> >> It still makes dlopen()ing the Cygwin DLL -- a technique which is used
> >> by Mono, Python ctypes, Ruby FFI, JNA, etc., and LD_PRELOAD hacks (among
> >> others) -- more complicated.  I'd prefer to revert.
> >>
> >> > 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?
> >>
> >> Not so sure about that first point; while ld (and w32api) wanted lib64,
> >> gcc wouldn't recognize it, at least not with a sys-root.  While
> >> doable, it does mean adjustments to cygport and some .cygport files,
> >> as well as patches (available in Fedora and other distros) for some
> >> packages which aren't lib64 aware.  If we don't need it, why bother?
> >>
> >> As for the future, I think we already agreed that trying to manage a
> >> fully multiarch distro isn't feasible with setup/upset.  If we're
> >> talking only about multiarch-ing Cygwin itself, I think a lib32/lib
> >> combination would do.
> >
> > Ok, let's go the full way.
> >
> > You *are* all aware that renaming the DLL back to cygwin1.dll means
> > that, afterwards, none of the currently existing binaries will work
> > anymore, right?
> 
> Fine by me. It would be silly to demand binary (or source) backward
> compatibilty at this point.

Right, but this means I will not be able to use 64 bit mintty and tcsh
for at least... a few hours.  You don't know what you're asking!!!


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]