[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some fixes for cygwin

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 works

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]