Am 19.03.2015 um 23:34 schrieb Lex Trotman:
On 19 March 2015 at 09:16, Thomas Martitz <ku...@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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
