This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Re: RFC: Cygwin 64 bit?
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:
bin/foo.exe
bin64/foo.exe
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat