Re: Resurrect discussion: Mixing 32 and 64 bit distro

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 14 00:01, Yaakov wrote:
> 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. :-)

Yeah, and that's why I was waiting for your reply :)

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

I don't remember what I thought or wrote in 2011, but I don't think the
buyout licensees are a good argument anyway.  The reason for the BL is
so that the licensees can generate proprietary projects with a Cygwin
DLL under the hood.  The license is bound to the project it was
purchased for.  And "proprietary" implies that the projects are
generated as closed solutions for customers of the licensee.

The existing projects have been built and packed for 32 bit.  They have
nothing to do with the distro and run entirely independently.  Apart
from that, we will support 32 bit Cygwin for the foreseeable future, and
nothing speaks against keeping such a project 32 bit, or providing two
separate 32 bit and 64 bit versions of the same project.

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

Indeed.  Building packages on behalf of a maintainer only having a 32
bit system should not be much of a problem.  Also, the build farm for 64
bit is a good idea, and our dept at Red Hat is inclined to provide it.

But instead of a farm, it might be even sufficient to provide a simple
mechanism for maintainers to build their package on a 64 bit machine via
mail:

Send your cygport file to cygwin-64-build-package AT redhat DOT com, and
a dedicated 64 bit Cygwin machine will try to build your package.
Results of the cygport output via mail reply. On success, packages will
be uploaded to sourceware automatically.  Using this mechanism would
just require to use cygport for packaging and everybody 

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

Isn't adopting packages already easy enough by just fetching the
existing source package from sourceware?

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

Our packages are missing the platform bits anyway right now, since they
were never necessary with only one supported platform.  In theory the
above problem requires to separate the -devel package in -headers,
-devel32 and -devel64.  But, yes, it's getting a lot more complicated.

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

Sigh, yes, I noticed that already myself.  I didn't take that serious
two years ago since it sounded easy to fix.

Ok, so far we have three voices for keeping 32 and 64 bit separate,
one voice for mixing them, and one being very unsure.

Any more input?


Corinna

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