This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
On Thu, 2011-07-07 at 17:00 +0200, Corinna Vinschen wrote:
> On Jul 7 09:22, Earnie wrote:
> > True but if the full path to the DLL is supplied in LoadLibrary then
> > only that directory will be searched.
>
> That's what we do in dlopen anyway.
However non-module shared libraries are usually dlopen()ed without an
absolute path, relying on [LD_LIBRARY_]PATH to find them, since they are
there anyway.
> > can control its own search path even using LD_LIBRARY_PATH. Prefixing
> > the /lib64 directory to PATH before the CreateProcess ensures that the
> > DLL can be found by the Windows OS for the starting application.
>
> 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"?
> > 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?
Yaakov