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 Sat, 2011-07-02 at 08:53 +0200, Corinna Vinschen wrote:
> 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.

How is this "moving over to 64-bit" if all the binaries are still 32-bit
(not having been ported yet)?  

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

It's a shame that RH (apparently) won't invest some money back into
Cygwin to make it the full-fledged distro that it can be.  Once Cygwin
itself is ported, it shouldn't take a full-time employee that long to
get a 64-bit distro up and running.

> And since there's no techical reason which disallows to have a
> mixed 32/64 bit distro, why not do it gradually?

The technical reason is this whole naming business.

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

Fine, but what *else* do they depend on?  On Linux, you have binary apps
which use GTK+ or Qt, meaning that you need those entire stacks
available in 32-bit, including the X.Org libraries, graphics libraries,
D-Bus, and other dependencies.

I seriously doubt *those* kind of binary apps exist for Cygwin.  If they
only depend on cygwin1.dll itself, then only the cygwin package needs to
be multilib, and THAT'S IT.  (There aren't that many packages that
dlopen() libc directly, I might be able to manage that much.)  Or if
we're talking about a small handful of basic libraries ("statically"
linked, where dlopen()ing isn't an issue), then we could keep the
traditional naming and get away with providing cygwin32-*
"cross-compile" packages in the sysroot, and append the sysroot bindir
to PATH (cygwin would still be multilib and both in /usr/bin).  In fact,
that solution might work even for more than a small handful, now that I
think about it.

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

Somehow that sounds dangerous, but I'll reserve judgement until I see a
patch.


Yaakov



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