Re: Resurrect discussion: Mixing 32 and 64 bit distro

[Yaakov (Cygwin/X) <yselkowitz at users dot sourceforge dot net>]

On Tue, 12 Feb 2013 14:40:04 +0100, Corinna Vinschen wrote:
> As you may or may not remember, we had a discussion about how to go
> forward with a 64 bit distro in 2011.
> 
> In this discussion I held vehemently to the view that we have to create
> the 64 bit distro in a way which allows to mix Cygwin 64 and 32 bit
> applications freely. 

And I just as vehemently disagreed. :-)

To recap: on Linux, 64bit platforms (especially x86_64) provide 32bit
compatibility libraries for the benefit of some very popular 3rd party
binary-only packages, which have (at least, until recently) generally
only been 32bit.  On Cygwin, those just don't exist, nor could they
without a licence buyout from RH; if any do, their user base isn't
large enough to justify this.  IMHO, this would just add a lot of
work for very little gain.

If I'm wrong on that count -- and obviously I have no knowledge of who
has licence buyouts from RH and what they are used for -- then my
question is: do these binary packages depend on any other libraries
besides cygwin1.dll?  If not, then *maybe* it would justify making
*only* cygwin multilib (in a lib32/lib arrangement), with the 64bit
cygwin1.dll in /usr/bin and the 32bit cygwin1.dll elsewhere or, as
cgf suggested, using a WoW64-like wrapper.  But to go multilib any
further than that just isn't feasible IMO.

> My main point was that it may take a long time
> until we get all the Cygwin 32 bit packages built for 64 bit, and
> therefore have to provide a mix so that users can adopt the 64 bit
> distro early without having to drop the tools they are using.

For some maintainers, this isn't a question of when but if; not
all maintainers has 64bit systems, and requiring them may be an
imposition for those who wish to contribute.  Perhaps we should poll
current maintainers to see how big of a problem we're facing, but
either we get a build farm so that maintainers don't have to build their
packages on their own machines, or some of us are going to have to
help maintainers with their 64bit packages.

Regardless, a helpful step would be to have per-package git repos on
sourceware, like I have currently on cygwin-ports.git.sf.net.  This
would open up the package maintenance process and hopefully make it
easier for others to help with, or adopt, existing packages.

> setup will also get pretty complicated, because you have to differ
> between 64/32 bit apps and 64/32 bit libs and setup has to know all the
> time which version it installs and to make sure to pull in the right
> libs.  This is easy enough with rpm, but, AFAIK, nothing of that sort is
> available in setup or upset yet.

Also, setup doesn't handle file collisions well, so while it (other
problems aside) could theoretically be made to work for runtime DLLs
with libfooN and lib64fooN (with libfoo-common.noarch where necessary),
how would 64bit libdevel packages work?  libfoo-devel for lib64fooN on
64bit and libfooN on 32bit?  Or libfoo-devel and lib64foo-devel, whose
headers would collide?  Too bad RPM isn't an option; setup/upset just
aren't up to this.

> Another, more development oriented downside is the fact that we have to
> introduce the cyg64 DLL prefix, which, as far as I remember from the
> discussion in 2011, breaks libtool and potentially configury and/or
> Makefiles of a couple of packages.

It would break every build system used to build libraries, as well as
programs which dlopen() prefixed libraries, of which there are many.
I assure you that it's a *very* big deal.


Yaakov