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


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