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 Aug  7 10:44, JonY wrote:
> On 8/7/2011 03:36, Christopher Faylor wrote:
> > On Sat, Aug 06, 2011 at 04:43:42PM +0800, JonY wrote:
> >> On 7/2/2011 01:00, Christopher Faylor wrote:
> >>>>> Also, in 5 years when nobody is running 32 bit windows, will everybody
> >>>>> still be happy with all these 64s in their paths and filenames?
> >>>>
> >>
> >> They said that about Win9x, but they're still around :)
> > 
> > Watch your attributions: that quote came from Brendan Conoboy.  But,
> > regardless, your response doesn't make much sense.  We didn't create a
> > cygwin9x directory for Windows 9x and we didn't change the mount point
> > for cygwin for Cygwin 1.7.
> 
> OK, but Win9x still lying around comes from my personal experience.
> 
> Most programs that were built under Cygwin 1.5 kind of still work when
> used under Cygwin 1.7, so no need for a separate cygwin9x. I don't see
> how that will apply to 64bit Cygwin interacting with 32bit DLLs unless
> some special loader tricks are applied.

You missed the test Yaakov made and published within this thread(*).
If you have two DLLs with the same name in the search path, one of them
a 32 bit and one of them a 64 bit DLL, then a 64 bit application will
pick up the 64 bit DLL regardless of the order in which they are found.

I think we should just keep the 64 bit DLLs (except for cygwin1-64.dll
itself!) in /lib64 == /usr/lib64 and add it to the path in some way.
Cygwin can add /usr/lib64 to $PATH in the startup.

I have a POC running locally which does exactly that.  This settles the
problem to find the DLLs for all Cygwin processes in a Cygwin process
tree, except for the first one, the parent of the tree.  Unfortunately,
it turned out that the parent can't change the search path for itself:

I moved one of the DLLs needed by tcsh, cygcatgets1.dll, to /lib64.
When I start mintty, which is only linked against the Cygwin DLL,
everything's fine.  At startup, Cygwin adds C:\cygwin\lib64 to $PATH, so
when mintty starts tcsh, it just works.

However, if I try to start tcsh by double click, Windows complains
that it can't find cygcatgets1.dll.  Obviously cygcatgets1.dll is 
linked against the Cygwin DLL, too, so one would expect that the
Cygwin DLL is loaded before cygcatgets1.dll.  But apparently Windows
loads all DLLs first, then it runs the DLL initialization functions.

What we can do is to ignore this problem.  That would mean, 64 bit
Cygwin would have a small restriction.  Either you add /lib64 to $PATH
in the global environment or in a batch file before you start a Cygwin
process, or you run your Cygwin processes via mintty.

Is that acceptable?  I'm not sure.


Corinna


(*) http://cygwin.com/ml/cygwin-developers/2011-07/msg00023.html

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