DLL loading

[Ryan Johnson]

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