|
From: | Charles Wilson |
Subject: | Re: Some fixes for cygwin |
Date: | Mon, 03 Jun 2002 01:03:03 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 |
Robert Collins wrote:
Exactly. The dlpreopen capability is transparent, the user thinks they are using dlopen... even when statically linked. I'll need to check the failing test source to see if my suggestion makes sense there. And yes, it would be 100% transparent. Gcc has an attribute for functions that makes them a constructor, they get called before main() :}.
<showing ignorance>But what exactly are "modules" in the libtool sense? Are they shared libs that are not explicitly linked to my app, but my app will dlopen() them on demand?
....checking source code.... Yep, seems that way.Okay, so given that, then doesn't dlopen() take a full path? If *that* is so, then I don't understand why the test is failing: dlopen() -- even on windows -- doesn't need the dll to be in the PATH since it is being explicitly referenced. I think...
</showing ignorance>
Hmm. I'm also not keen on this. Like the shell wrapper it only worksin-cygwin.
True -- unless the end user adds /usr/share/my_toy to their PATH from System->Environment or autoexec.bat.
There's just something about dlpreopen that bugs me...but I can't quite put my finger on it. Something about on-demand loading of modules that you didn't know existed back when the executable was linked...but were later compiled and installed into the my_toy/ modules directory. Or maybe I'm thinking about something that's in the DCOM/CORBA/RMI/Kparts/Bonobo domain, and isn't really something libtool worries about...
--Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |