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] |
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] |