2018-05-20 21:44 GMT+02:00 Juergen Sauermann <[email protected]>:
> As far as I understand, there are two ways to link libapl with your > application: > > 1. link it at compile time (with the -lapl linker option) or > 2. dlopen() it at runtime (your approach). > > In case 2. the symbol init_libapl is NOT resolved by dlopen() but has to be > resolved via dlsym() and > then called with the return value of dlsym(). There might also exist some > (usually platform specific) linker options that > cause dlopen() to resolve all symbols provided in a shared library > automatically, but I don't know. > > I should mention that libapl is mainly a work of Dirk Laurie, I suppose he > does not use dlopen(), but uses approach 1. > Maybe Dirk can give you some more hints about how to use libapl. I did this three years ago, using SVN 570 of GNU APL. In an ideal world, I would have checked after every SVN update that my application still works. In the real world, I have not touched it since and cannot remember much. :-( I currently have SVN 1048. When I tried it my application [1] (which runs GNU APL in parallel with Lua) just now, the Lua 5.2 version that I made on 29 May 2015 still works in a simple test. $ lua -l gnuapl Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio > …/gnuapl$ lua5.2 -l gnuapl Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio > =gnuapl.exec"4 4⍴⍳16" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > This seems to confirm that there is nothing wrong with libapl.so. Unfortunately I have no simple C main program, since everything runs through Lua. In particular, Lua's 'package.loadlib' function is used to load the current libapl.so. The code for that function is way above my code-reading ability. Sorry that I can't offer more help. -- Dirk [1] Those that are reasonably fluent in Lua and its C API can try it out: https://github.com/dlaurie/lua-gnuapl
