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

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

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

Even given those issues with upstream "culture", I think the build
systems are actually a MINOR part of the problem: basically, you fix the
build system problem and then all the USERS of those build systems are
(mostly, more or less) fixed. One stop shopping.

> Secondly, this affects much more than build systems.  Any program that
> dlopen()s libraries/modules needs to know how their named.  Between
> Ports and the distro, I deal with some 2000 source packages (just
> checked), and I can tell you that literally HUNDREDS would need to be
> patched to accomodate such a change.  Even changing the name of
> "cygwin1.dll" would affect packages which dlopen() it, and they do exist
> (mono is a prime example).

This is, to me, the big issue with a "new" prefix.  All the dlopen() and
LoadLibrary() code out there that must change.

Now, I *HAD* supposed that, during this massive effort Yaakov describes
above, that all these source patches ended up with something like:

was:
    dlopen("libfoo.so")

now:

#ifdef __CYGWIN__
# define LIBPREFIX "cyg"
# define LIBVERSUF "-2"
#else
# define LIBPREFIX "lib"
# define LIBVERSUF ""
#endif
...

sprintf(buf, "%sfoo%s", LIBPREFIX, LIBVERSUF);
dlopen(buf)

Which could now, easily be changed by the addition of a new
	#if defined __CYGWIN__ && defined X86_64
	# define LIBPREFIX "cyg64"
	# define LIBVERSUF "-2"
        #endif
clause, but Yaakov has said, upthread, that I was wrong.

> http://bugzilla.gnome.org/show_bug.cgi?id=638322
> 
> Thanks to this guy, I'm stuck patching dconf (an essential component of
> GNOME 3) indefinitely.  Every patch that I have to carry (or struggle to
> push upstream) is that much more effort for me.

Some people are jerks.  Looks like you found one.

I just hope that gnome/gtk (or, for that matter, qt/kde) don't ever
become directly dependent on systemd.  Linux only, forever...


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?

We could also "shim" the LoadLibrary in the 64bit version of w32api to
do the same thing, but I think that's overkill.

That at least "solves" the dlopen() problem, leaving "just" the build
system issue -- which IMO is at least more "localizzed" to just a
handful of packages rather than your 2000 dlopen fixes.

--
Chuck


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