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] |
On May 24 11:47, Charles Wilson wrotWorse, 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.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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |