Am 19.03.2015 um 23:34 schrieb Lex Trotman:
On 19 March 2015 at 09:16, Thomas Martitz kugel@rockbox.org wrote: There is no other way of loading C shared libraries and registering them as plugins.
Doesn't Geany already load dlls local and extract the symbols it wants via dlsym()?
dlsym() takes an argument of the loaded dll handle, so it can't access the wrong library.
Yes, there is no problem in this if accesses go through dlsym with the appropriate library handle. Global namespace collisions can occur of symbols exported by multiple shared libraries are accessed the normal way, either by geany or plugins. This happens in the current loader, as plugins access their geany_plugin pointer (but does not happen under my new loader). As we use RTLD_LOCAL so we have no problems here either, however it is still nice to have to minimize the amount of globals exported by the plugin.
API/ABI just a typo :) Note that allowing the plugin to make this decision means it has to have a way of overriding the default >= test you have moved into geany.
I can't follow this.
But indeed, the API version could be passed to geany_load_module() to allow for the above. Passing the abi version is pretty useless as the plugin will only load with one specific abi anyway so it can't adapt.
Also it would be good to consider the semantics of API and ABI since there are some conditions where we cannot express a change in the interface except for the hammer of an ABI break.
We should be able with the new loader mechanism, since we learn about the plugin's minimum API version. Now we can not only deny based on the ABI version but also based on the minimum API (we could possibly deny loading plugins which are written against too old API version).
The decision of "too old" needs to be made by the plugin, Geany doesn't know what the plugin uses, that a plugin declares "I can run with any API newer than 123" doesn't mean it actually uses 123. It is just being friendly and saying "I can run with older Geany's as well".
The plugin may know it better, that's why I follow your suggestion and pass Geany's API version to geany_load_module.
I was saying that we could deny loading plugins that report 123 as their minimum if we made an incompatible API break in 130 like removing a function all together. While it's true that 123 doesn't mean it uses that very function, Geany could be conservative and deny loading. (I know this was a bad example because we bump the ABI for removed functions, and plugins that use the removed function would not recompile successfully, but you get the idea).
Best regards