RFC: Cygwin 64 bit?
Fri Jul 1 23:40:00 GMT 2011
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.
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?
> 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). And there
are other build systems out there (e.g. GNUstep, qmake, scons, waf).
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).
Frankly, I'm a volunteer, and while I enjoy the challenge of
accomplishing the supposedly "impossible" on Cygwin, the cost-to-benefit
ratio for such a change doesn't make me want to deal with this.
> Today it seems like no problem at all to create a package providing shared
> libs on Cygwin.
True, all the work on the toolchain and libtool over the years has
certainly helped, but there is still much work to be done; take this for
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.
> Why should that be worse with another prefix for 64 bit Cygwin DLLs?
It's really the change to dlopen()ed module naming which makes this such
a big deal, and it's a major factor when you get to the desktop.
And no, using "cyg64" for "libraries" and /usr/lib64/**/"cyg" for
"modules" is NOT a solution either; many "libraries" are dlopen()ed
under various circumstances, so everything needs to have the same
> Btw., if people don't like the looks of cyg64, I could also live with
> some simple cygx, cygxx, xcyg, or so, without a number.
Bottom line, it's not about "looks", it's about changing the standard.
More information about the Cygwin-developers