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 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.
Andy