Re: RFC: Cygwin 64 bit?

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

On Jul  2 01:11, Charles Wilson wrote:
> On 7/1/2011 7:40 PM, Yaakov (Cygwin/X) wrote:
> > On Fri, 2011-07-01 at 19:51 +0200, Corinna Vinschen wrote:
> >> And, while we're at it, I'm still missing an explanation why cyg64 is an
> >> even worse problem than the cyg prefix.  The cyg prefix solved a
> >> problem.  The cyg64 prefix would solve another problem.  
> > 
> > And I'm still missing a reason for why this is necessary in the first
> > place.  The use case for multilib is to run third-party binary-only
> > packages, which are usually only available for 32-bit.  On Linux, there
> > are plenty of them.  On Cygwin, I have yet to see one, and even you
> > couldn't provide a concrete example.
> 
> No, I think in this case there are two motivations -- one we can easily
> quantify, and the other somewhat nebulous.
> 
> 1) The ability to have a "gradual" switchover, on a win64 system, from a
> pure 32-bit installation, to a bi-arch 32bit/64bit where MOST everything
> is 32bit, except for cygwin64-1.dll and a few core utilities, to
> (finally) a "pure" 64bit system.  During the transition period --
> however long it is -- as more and more DLLs are ported/released as
> 64bit, nothing actually BREAKS because the 32bit versions are all there
> and are usuable by the 32bit apps (and the special cooperation between
> cygwin1.dll and cygwin64-1.dll that Corinna was talking about).
> 
> In fact, until the user upgraded "foo.exe" from its original 32bit
> incarnation to its new 64bit one (which then uses all those, til now,
> unused cyg64xxx-N.dlls we'd been busily porting), very LITTLE changes
> for the end user at all.
> 
> Then, as we gradually provide more and more cyg64*dll and foo.exe(64),
> the installation /gradually/ becomes more and more 64ish.  No big flag
> day.  No "mostly broken, not really ready, but pretty pretty please
> PLEASE test it for us...PLEASE?"  It's just *THE* installation you GET
> when you install on a 64bit machine -- and it WORKS just like the 32bit
> installation does today.

That's it, more or less.  The big advanatage in my eyes is that this
gives the user an early choice to move over to 64 bit.  This in turn
gives us much more testing and more flexibility.

Call me a pessimist, but I expect that the process of getting a full 64
bit distro will take a long time.  I don't think it is feasible to assume
we can manage the whole process in one big chunk and have a full working
distro at the end which we then present to the users.  It's just not
realistic.  And since there's no techical reason which disallows to have a
mixed 32/64 bit distro, why not do it gradually?

> > Since I don't know who RH's buyout customers are and what they do with
> > their buyout right, perhaps you could do some research on the subject?
> 
> 2) The whole "what do Red Hat's buyout customers need" issue. We really
> can't quantify this.

Neither can I!  As I said, we don't keep track of them closely, and even
the bits of information we have are under NDA, obviously.  But that
wasn't the point.  Yaakov asked for 32 bit binary apps and there are
some.  There's no reason to expect they don't exist.

> >> Libtool and other packages will adapt, they did that all the years.
> > 
> > They don't adapt by themselves; who's going to make them adapt?  Sure,
> > Chuck could handle libtool, but it took *over a year* to get my patches
> > into CMake (using "cyg" prefix for modules was part of that). 
> 
> Uh, well, it actually took about a year apiece, to get each major cygwin
> functionality improvement merged into upstream libtool.  Nobody really
> noticed, because I was shipping a modified version here all that time.
> 
> The problem boils down to poor upstream culture in those projects -- but
> cygwin shouldn't not let upstream malbehavior influence our technical
> decision.
> 
> > And there
> > are other build systems out there (e.g. GNUstep, qmake, scons, waf).
> [SNIP]
> Hey, Yaakov -- what about this wild idea:  What if, cygwin64-1.dll's
> implementation of dlopen() -- and remember, cygwin64-1.dll can only be
> linked/loaded by a 64bit process -- automatically translated all
> attempts to dlopen .../path/to/cyg*.dll to FIRST attempt to open
> cyg64*dll, then (if cyg*dll was actually 64bit, rather than the expected
> 32bit) fall back to the specified name?

I'm wondering why we didn't do this in the first place?  In theory
there's nothing which speaks against dlopen("/path/to/libfoo.so") to
check for valid combinations:

  - /path/to/libfoo.so
  - /path/to/libfoo.dll
  - /path/to/cygfoo.dll (32 bit) or /path/to/cyg64foo.dll (64 bit)

shouldn't that ease the pain?


Corinna

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