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: RFC: Cygwin 64 bit?


On 6/28/2011 3:33 PM, Corinna Vinschen wrote:
> On Jun 28 12:56, Charles Wilson wrote:
>> Which means that the 64bit dlls *must* have a different name, or we
>> can't have coexistence.  E.g.
>>
>> Oops.
> 
> Oops? 
> 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.

Right, we have to decide -- my point is there isn't an easy answer that
will have zero impact on everybody.  There are basically three choices:

  /bin + /bin64 -- affects $PATH, implicates package naming (*). Also
                   might affect script #! lines, and anything that calls
                   exec*() or spawn() with a full pathname.

  cyg64 prefix -- affects apps which dlopen() or LoadLibrary().
                  Especially affects the "big stacks" like Yaakov's
                  gnome and kde

  no multilib -- slows deployment and development of (crippled) cyg64
                 distro

(*) unless we combine 32 and 64 into the same package. More below.

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

That could work.  The downside is the maintainer's system: she is
running either 32bit or 64bit cygwin.

(1) maint=32bit: needs the native compiler to build the 32bit stuff, but
also needs a 64bit cross compiler.  Build system needs to support
building the [app/lib/whatever] twice: once native and once with the
64bit toolchain, and to "know" how to package it.

(2) maint=64bit: needs a "native" 64bit compiler, and a 32bit cross
compiler. Ditto as above, but reversed.

The bulk of cygwin packages are, at present, built using cygport.  It
does not (yet) have support for multiple build passes like this, but
that could be added relatively easily I think.

OTOH, if you're using gbs (or mknetrel, or Jan's tool-I-forgot-the-name)
you're looking at some hurt, I think.

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

Right, but it just seems odd to me that (eventually) the "pure" 64bit
cygwin will have all these "lib64fooN" packages everywhere, and all the
requires: lines in the setup.hints will need to list those, rather (or
in addition to?) than the "libfooN" one.  Doable, but...odd.

Plus, if you have 'fooapp' which depends  on libfoo, and fooapp is
available in both 32 and 64bit flavors, which DLL package does its
(single?) setup.hint list as a requires:?  Both of them?

--
Chuck


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