This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Resurrect discussion: Mixing 32 and 64 bit distro
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.
Yaakov