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: DLL loading


On 24/05/2011 12:45 PM, Corinna Vinschen wrote:
On May 24 11:47, Charles Wilson wrot
Now, for constructive ideas -- here's my brainstorm.  Maybe it's
workable, maybe not, I dunno:

Most of the problems appear to occur with apps that have a lot of
DLL-based plugin/extension libraries -- perl, python, octave.

What if we were to create a post-processing tool that package
maintainers could use, that could:
#1) merge a "new" DLL into a single common DLL
#2) modify (or recreate) the "new" DLL's implib to point at the common DLL.

Then, the build process for, say, perl, could be modified to;
1) build the extension DLL and its implib as normal
2) merge the new DLL into the "aggregate" one
3) rewrite/recreate the extension's implib to point to the aggregate
...rinse and repeat as needed.
That sounds rather ugly.  If you do that you load all plugins even if
you only need one.  That leads to the question why you don't just link
all plugins statically against the application.  You might also
encounter surprising low-memory situations.
Worse, what if the reason the user called dlclose in order to *replace* one version of the library/plugin with another? Symbol renaming would be exactly the wrong way to resolve collisions.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]