This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
On 27 June 2011 09:42, Corinna Vinschen wrote:
>> >> The situation is different with libraries, where the 32-bit versions
>> >> would need to stick around as long as there are still 32-bit
>> >> applications using them. Could this be handled with ABI bumps, so for
>> >> example libncurses10 would remain 32-bit, but libncurses11 would be
>> >> 64-bit? I think this would fit into the existing packaging
>> >> infrastructure.
>> >
>> > That's not an option, IMO.
>>
>> I'm probably missing something obvious, but why?
>
> Maybe I misunderstood you? ÂI thought you meant that libncurses10 is
> the last 32 bit version, libncurses11 is the first 64 bit version and
> that's that.
I did mean that, the implication being that if a package wanted to use
the latest libncurses, it would need to be ported to 64-bit, thereby
limiting the load for library maintainers and providing gentle
pressure towards getting everything ported.
It would also mean omitting support for building 32-bit binaries, in
particular 32-bit -devel packages. Cygwin 1.7 would still be there for
people who do need to build 32-bit stuff, and Cygwin 2 would be able
to run it.
The idea here is to support 32-bit only as far as needed to avoid
having to port the whole distro to 64-bit from day one. Obviously this
doesn't make sense if you don't want to relegate 32-bit to legacy
status.
>> > What speaks against doing it the Linux way,
>> > keeping 32 bit libs in {/usr}/lib and 64 bit libs in {/usr}/lib64?
>>
>> The prefix hackery that I presume is needed for this. Granted, since
>> Linux does it this way, it should already exist in most cases.
>
> It does. ÂOn a 64 bit Linux system you have a pretty distinction
> between the 32 bit stuff in lib and the 64 bit stuff in lib64.
>
>> > In addition we will probably need a {/usr}/bin64, due to the $PATH
>> > issue
>>
>> That one seems more hairy than lib64, unless others have this as well?
>
> They don't have to. ÂThis suggestion is based on the assumption that
> we will have 32 and 64 bit DLLs using the same name, and partially
> even 32 and 64 bit tools using the same name.
Of course. The point was that if no-one else does this, it's likely to
cause Cygwin-specific challenges. I don't really know what I'm talking
about here, but I think the basic issue would be install rules
assuming that binaries go into /bin, which wouldn't work if the 64-bit
DLLs are in /bin64.
> For instance, it would be most easy to keep the Cygwin 32bit package
> as it is, with all the tools like mkpasswd, mount, getfacl, etc.
> And the 64 bit package would look the same, just that it installs
> into /bin64.
With the scheme I outlined above, there could be a single 64-bit
'cygwin' package, version 2.x, much as it is now, plus a cygwin-legacy
package (or some such name) with the 32-bit DLL(s) only.
Andy