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 Jun 27 09:17, Andy Koppe wrote:
> On 27 June 2011 08:25, Corinna Vinschen wrote:
> > On Jun 27 06:49, Andy Koppe wrote:
> >> On 27 June 2011 04:08, JonY wrote:
> >> > I was thinking that 64bit Cygwin will be installed in a completely
> >> > separate directory so there is no chance in clobbering 32bit Cygwin
> >> > DLLs, like a parallel 1.5/1.7 install.
> >>
> >> A clean cut would be ideal, but I fear it would also greatly delay the
> >> project, because a large number of packages would need to be ported
> >> before the 64-bit distro would become viable for users. Supporting
> >> both 32-bit and 64-bit processes and having them interact seemlessly
> >> could avoid that.
> >
> > Just as on 64 bit Linux. ÂAnd just as on Linux there will be
> > applications which won't be ported to 64 bit for quite some time.
> >
> > AFAICS, the two DLLs can simply share all data and act as a unity.
> > There would be not much of a difference, except for running on a
> > different CPU, kind of. ÂTo the best of my knowledge there's no
> > reason to keep 64 and 32 bit separate.
> >
> >> This doesn't meant that Cygwin 2 (to coin a handle) still has to be
> >> installable on 32-bit systems, i.e. that 64-bit applications wouldn't
> >> still need 32-bit versions as well.
> >
> > There's still 32 bit Cygwin. Â I don't think we can neglect that.
> > And, as I said, there's no reason to do that.
> >
> >> The situation is different with libraries, where the 32-bit versions
> >> would need to stick around as long as there are still 32-bit
> >> applications using them. Could this be handled with ABI bumps, so for
> >> example libncurses10 would remain 32-bit, but libncurses11 would be
> >> 64-bit? I think this would fit into the existing packaging
> >> infrastructure.
> >
> > That's not an option, IMO.
> 
> I'm probably missing something obvious, but why?

Maybe I misunderstood you?  I thought you meant that libncurses10 is
the last 32 bit version, libncurses11 is the first 64 bit version and
that's that.  But now I guess you meant that libncurses10 and
libncurses11 are actually just the same thing, just for different
architectures.  Same for the next version which would become
libncurses12 and libncurses13, right?

That might be possible, but it might also be a tricky burden on stuff
like libtool.

> > What speaks against doing it the Linux way,
> > keeping 32 bit libs in {/usr}/lib and 64 bit libs in {/usr}/lib64?
> 
> The prefix hackery that I presume is needed for this. Granted, since
> Linux does it this way, it should already exist in most cases.

It does.  On a 64 bit Linux system you have a pretty distinction
between the 32 bit stuff in lib and the 64 bit stuff in lib64.

> > In addition we will probably need a {/usr}/bin64, due to the $PATH
> > issue
> 
> That one seems more hairy than lib64, unless others have this as well?

They don't have to.  This suggestion is based on the assumption that
we will have 32 and 64 bit DLLs using the same name, and partially
even 32 and 64 bit tools using the same name.

For instance, it would be most easy to keep the Cygwin 32bit package
as it is, with all the tools like mkpasswd, mount, getfacl, etc.
And the 64 bit package would look the same, just that it installs
into /bin64.

I don't claim that this is the way to go, far from it.  It's just
some vague idea how we could mix 32 and 64 bit most easily.


Corinna

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


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