RFC: Cygwin 64 bit?

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Jun 28 19:33:00 GMT 2011

On Jun 28 12:56, Charles Wilson wrote:
> 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.
> Oops.

Oops?  It's basically the same as on a 64 bit Linux.  32 bit libs go
to /lib, 64 bit libs go to /lib64.  It's just a bit different for DLLs
because they are in /bin.  Either we invent a /bin64, or we use another
DLL prefix, like the suggested cyg64.  I don't see much of a problem here.
It's just a decision to be made, isn't it?

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

Well, depends on how you create packages.  Another decision to be made.
I'll go with the flow, but I can easily imagine that a package maintainer
just provides 32 and 64 bit stuff in the same package and setup decides
what to do.  For instance, the package is packed like this:


Now setup installs bin/foo.exe unconditionally and, as soon as it
trips over bin64/foo.exe it depends on the system it's running on.
On a 64 bit system it installs bin64/foo.exe to bin/foo.exe, on a
32 bit system it simply ignores everything under bin64.

Well, it's just an idea, there are certainly better ones.

> 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):
> tiff
> tiff-doc
> tiff-opengl
> libtiff-devel
> >>> libtiff6 <<<
> Now, on my (64bit) linux box, the following two packages do not conflict
> (*).
> libtiff-3.9.5-1.fc15.x86_64
> libtiff-3.9.5-1.fc15.i686
> 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).

But there's no rule which disallows to provide another package called,
say, lib64tiff6.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list