RFC: Cygwin 64 bit?

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Jun 28 16:57:00 GMT 2011

On 2:59 PM, Corinna Vinschen wrote:
>> What does Linux do?
> Executables in /{s}bin, /usr/{s}bin, regardless of 32 or 64 bit.
> Libs in /lib vs. /lib64, /usr/lib vs. /usr/lib64.
>> (Also, do libraries still need to go into the same directory as executables?)
> Yes, %PATH% still rulez.

Which means that the 64bit dlls *must* have a different name, or we
can't have coexistence.  E.g.
  bin/app1.exe is not yet ported to 64, and uses (32bit) cygz-1.dll
  bin/app2.exe IS ported to 64, so obviously needs the (64bit) zlib dll?
If a 64bit zlib DLL is available, then we need to have both installed,
without conflicts -- which means (a) different DLL name OR different
location for both 64bit DLLs AND EXEs, and (b) different PACKAGE name.


So, if 64 and 32 are to coexist in the same installation, we need to
worry not just about DLL names, but also the name of packages (at least,
for delivery of DLLs).

Currently, most package sets that deliver general purpose (i.e.
non-private) DLLs do so in a separate "library" package (zlib,
ironically, being an exception):


>>> libtiff6 <<<

Now, on my (64bit) linux box, the following two packages do not conflict


So, the first observation is that the "package name" includes the
bitness of the binary. None of our package names do this, at present
(not counting the mingw64 cross compilers).

Now, in the linux case, the .so's themselves DO have the same name --
they just get installed into separate directories:


However, if we only have one 'bin' directory for both 32 and 64 bit
exe/dlls, then...we need to give the DLLs different names, as well. I
like the prefix idea -- and I'll push it on libtool if necessary.

(*) Well, they do, but not with regards to the shared libraries
themselves.  Both linux packages install the following:

>>>  - Do we define "long" as 32 bit or 64 bit type?
>> Oooh, that's a difficult one. (For anyone who doesn't know: It's 64
>> bits on Linux, but 32 bits on Windows, including MinGW-64.)
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
> bugs me.  There's no _CS_POSIX_V7_xxx definition which allows for 32
> bit int, 32 bit long, 64 bit pointer and 64 bit off_t.

Yep.  sizeof(long) != sizeof(void*)...Bad Microsort! No cookie!


More information about the Cygwin-developers mailing list