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: RFC: Cygwin 64 bit?


On 6/27/2011 1:17 AM, Andy Koppe wrote:
>> 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.
> 
>> In addition we will probably need a {/usr}/bin64, due to the $PATH
>> issue

Why?

Today, Cygwin DLLs all have the form cyg$SONAME.dll. In a 64-bit Cygwin,
32-bit DLLs would retain this naming convention and 64-bit DLLs would be
named cyg64$SONAME.dll. Executables and both kinds of DLL would still go
in /bin, allowing either the 32-bit or the 64-bit version of a program
to be installed, but not both. (Different word length binaries could
exist in another directory, of course.) Static libraries and import
libraries would go in /lib and /lib64 for 32- and 64-bit versions,
respectively, with the compiler choosing the correct option.

As for the choice between LP64 and LLP64 --- would it be evil to make
long 64-bit, but define DWORD, LONG, ULONG and so on to be 32 bits wide?
This way, both Windowsish and POSIXish code will continue to work fine.
Of course, this scheme breaks anything assumes sizeof(long) ==
sizeof(LONG), but every available option will break something.

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]