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 18 07:51, Ryan Johnson wrote:
> On 18/08/2011 5:20 AM, Corinna Vinschen wrote:
> >So, nobody except Earnie is interested in the way dlopen opens shared
> >objects?  Nobody even replied to the idea of the pseudo algorithm below.
> >Does really nobody care?
> The below looks fine to me, but I really didn't feel qualified to
> comment. I had been lurking on this thread because I really don't
> know much about the ins and outs of the Windows loader...
> 
> That said, it seemed from a different part of the thread that it
> should be possible to wire in relative ../lib/ paths for dlls in
> such a way that we'd no longer need to keep them in bin. It seems
> like that would be a good avenue to pursue, because then the normal
> ../lib and ../lib64 conventions would solve the problem of a mixed
> 32/64-bit distribution pretty nicely. Maybe we could even

Unfortunately, it doesn't seem to be really feasible to hardcode
../lib/my_beloved.dll in executables and other DLLs.  The problem is, at
the time of building the DLL you don't really know if it will be
installed in ../lib.  This is typically only known in the `make install'
stage, which is a bit too late.  I don't see an easy way to automate
this behaviour :(

> If the above worked, then adding /usr/bin to the dlopen search path
> would then be harmless but unnecessary. Or maybe I'm completely
> misunderstanding things?

Uh, maybe I should have explained this better.

Right now, without my patch, if tonly a DLL name is given, the following
happens:

  incoming: cygfoo.dll
  abspath?  No
  Exists with one of LD_LIBRARY_PATH prepended? No
  Exists in /usr/lib? No
  ==> cygfoo.dll stays intact and LoadLibrary is called with "cygfoo.dll"
  This in turn means, the DLL is searched in the default DLL search path
  by Windows.

I removed the latter part in my patch, so the default DLL search path is
never used, so /usr/bin is not searched either.

Hmm.  On second thought I'm wondering if that's a good idea.

On one hand, Linux does not search in the directory from which the
application got loaded, and it also doesn't search in the current
working directory, so from that POV my change is ok.

On the other hand, it might break existing code which contains stuff
like

  dlopen ("ntdll.dll", RTLD_LAZY);

Given the latter I should problably drop /usr/bin again and allow
LoadLibrary to search in the default search path...


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]