Resurrect discussion: Mixing 32 and 64 bit distro

[Ryan Johnson]

On 12/02/2013 8:40 AM, Corinna Vinschen wrote:
> Hi guys,
>
>
> I slept a bit bad tonight.
>
> 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.  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.
>
> But is that really so?  I'm not so sure anymore.  Maybe that problem
> is exaggerated or overvalued.
>
> The communication between 32 and 64 bit processes is rather complicated.
> While carefully maintained shared mem regions are not much of a problem,
> the dll shared section is, since it's not shared anymore.  Also, parts
> of the information given to a process at spawn/execve time has to be
> serialized, mainly the stuff from cygheap which needs to be inherited by
> the child.  Information easily available in /proc isn't that easily
> available anymore when you have to share it between 342 and 64 bit
> processes.
>
> 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.
>
> 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.
>
> So, I'm inclined to resurrect this discussion.  I'd like to hear your
> point of view and why you're rating one over the other (separate
> distro vs. mixed distro).  Personally I'm really not sure what is
> more important, a full distro right from the start, or a clean
> separation.
Two thoughts:

1. How is this significantly different for the end user than the 1.5 -> 
1.7 migration was? That essentially required a full upgrade as well, 
with no inter-op allowed, and side-by-side installs common for a while. 
I don't know how much pain it was for the package maintainers to get 
their stuff working under 1.7 -- presumably at least a couple ran into 
issues.

2. How much pain do we really expect the package maintainers to see 
because of 32-bit -> 64-bit migration? Most open source packages have 
been 64-bit capable for years now, which should rule out the majority of 
subtle integer truncation bugs and leave mostly configury/#define issues 
to deal with.

I'd suggest that a few brave maintainers try creating 64-bit packages 
(mintty already seems to work), and if it goes relatively smoothly we 
forget mixing; folks whose favorite package is missing at first can just 
keep using 32-bit 1.7 until the early adopters have broken a path for them.

BTW, would it make any sense to talk about having 32-bit binaries made 
for 64-bit cygwin, compiling them specially for inter-op with a 64-bit 
cygwin1.dll? Kind of how most 64-bit linux default to 32-bit binaries on 
a 64-bit kernel? There are fairly good reasons for small binaries 
operating on small datasets to stay 32-bit, but I don't know if that's 
really possible, given the issues you mention above. The 32-bit vs 
64-bit .dll situation seems especially icky.

$0.02
Ryan