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 Jul  7 21:26, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-07-07 at 17:00 +0200, Corinna Vinschen wrote:
> > No, that does not help.  See the DLL search order in
> > http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx
> > 
> > The path from which the application started is always first.  The
> > current working directory is always prior to the paths from $PATH.
> > Whatever you do, if you're in the wrong dir it goes boom.
> 
> So if the DLLs were in /usr/lib{,64}, and we started a 64-bit program
> with CWD of /usr/lib, then it goes boom.  Under what circumstances would
> CWD be /usr/lib* that this would be a concern in the first place?
> 
> Or why can't we make sure to always pass LoadLibrary an absolute path,
> making sure to reject any which are "wrong-bit"?

LoadLibrary is only used in dlopen.  That's not the problematic case for
going boom.  The problem is fork/exec with its underlying call to
CreateProcess.  We can't change how the DLLs are loaded by the Windows
loader.  Again, see what I wrote in the quote above.

But also see below(*)!

> > > I'm dreaming here trying to get past
> > > this issue for cyg128.  If every use of a library were RUN TIME instead
> > > of LOAD TIME then you can segregate easier the library bitness into
> > > differing directories such as lib64.
> > 
> > I still don't see the problem t use a cyg64 prefix.  It fixes almost
> > all problems, and the potential problems with dynamic loading can be
> > handled within dlopen.
> 
> Wouldn't changing dlopen() to compute absolute paths for LoadLibrary()
> be easier (and perhaps safer) than changing the former to manipulate
> various permutations of DLL names?

Have a look into the sources.  dlopen already computes the full path
before calling LoadLibrary.  Permuting the prefixes was supposed to
fix another problem:

  application is dumb and calls dlopen("cygfoo.dll") on a 64 bit
  system

  dlopen is clever and tries dlopen("cyg64foo.dll") first.

See Chuck's mail here:
http://cygwin.com/ml/cygwin-developers/2011-07/msg00006.html


(*) Actually, come to think of it, I never really *tried* if that
    problem actually exists.

    Setup: Create a Mingw 32 and 64 bit DLL using the same name
    like libfoo.dll with an entry point foo.  Store the 64 bit
    DLL somewhere in $PATH, keep the 32 bit DLL in $CWD.  Create
    a 64 bit application calling foo().  Run the application.
    Does it work or does it go boom?  Same test for an application
    loading libfoo at runtime via LoadLibrary.

    Without actually knowing what happens, we're practically just
    speculating.  That's probably not the way to solve the problem.

    Yaakov, would you mind to do such a test and report back?


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]