swipl-devel
swipl-devel copied to clipboard
SWI-Prolog
Are use of `dlopen` necessary
Per https://github.com/emscripten-core/emscripten/issues/19141#issuecomment-1498443649 - dlopen usages appear to be causing problems with the webassembly builds of this library - I'm wondering if they can be removed.
Surely, if there are calls to dlopen, they can be #ifdef'ed for the STATIC_EXTENSIONS setup.
Perhaps its an extra conditional required here (https://github.com/SWI-Prolog/swipl-devel/blob/13d22dd197a89df4c2f33dc21da612c2d6dd85a6/src/pl-load.c#L110)?
The full list of dlopen references I can find is at https://github.com/search?q=repo%3ASWI-Prolog%2Fswipl-devel%20dlopen&type=code.
I'd offer to help but unfortunately I don't have enough experience with the core codebase to do it in a reasonable amount of time - and I am generally time poor at the moment.
Yes. Part of the code is already disabled under O_STATIC_EXTENSIONS and replaced by other code (to call the init functions of the statically added components). Propably we should simply disable more. We do not want all the predicates for loading and unloading shared objects and their helpers.
I think there was some sort of handling of dlopen on my emscripten branch? you might check, at least.
On Fri, Apr 7, 2023, 04:22 Jan Wielemaker @.***> wrote:
Yes. Part of the code is already disabled under O_STATIC_EXTENSIONS and replaced by other code (to call the init functions of the statically added components). Propably we should simply disable more. We do not want all the predicates for loading and unloading shared objects and their helpers.
— Reply to this email directly, view it on GitHub https://github.com/SWI-Prolog/swipl-devel/issues/1158#issuecomment-1500062901, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAET46IECUXIK2PL5DLB7SLW77FCZANCNFSM6AAAAAAWWFVXBI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I think there was some sort of handling of dlopen on my emscripten branch?
Considering the warnings against dynamic loading in the Emscripten docs I tried a different route, allowing extensions to be linked statically. That is the O_STATIC_EXTENSIONS. It compiles the extension to a static lib, generates a C file with a data structure that links the library name to its init function and links the whole thing statically. Next, "linking" such a library using use_foreign_library/1 simply looks up and calls the init function.
Possibly we want that different at some point. For now, this is fairly simple and the main disadvantage is that it is not so easy to get user extensions into this framework. Ideally we'd move such extensions to use CMake with some cmake include file provided by Prolog that allows this to work.