Tcl/Tk
Per Hedeland
per@REDACTED
Tue Mar 28 10:06:18 CEST 2000
Ljung Magnus <etxmljg@REDACTED> wrote:
>Like always when calling out for help you find part of the solution at the same
>instance. A simple way to get access to the Erlang libraries is to re-compile
>Tcl with a function call to them included in the sourcecode.
That may work in this case, but not in general I think. Only objects
(i.e. .o files) in an archive that satisfy unresolved references will be
included with the binary, thus objects that are only called from your
loadable object will still be missing at runtime. If it works, it's
because the function you call directly from tcl in turn, directly or
indirectly, calls enough other functions to pull in all the needed
objects. Plus of course it will make the erl_interface libraries
"bundled" with tcl rather than with your shared object, which is
probably not what you wanted.
> This is not the
>best solution but gives me the possibility to proceed until I find something
>better.
Did you even try the trivial one I suggested? Here's a simplified
demonstration to show that it works (and that Per B is partially
wrong:-) - run on Solaris 2.6 (I assume Solaris from your -R, you didn't
say what OS it was):
% cat app.c
foo(){erl_init_nothreads();}
% gcc -O2 -shared -fPIC -L/usr/local/lib/erlang/lib/erl_interface-3.2/lib -lerl_interface app.c -o app.so
% ls -l app.so
-rwxr-xr-x 1 per 23836 Mar 28 09:51 app.so
% nm app.so | grep erl_init_nothreads
[82] | 0| 0|NOTY |GLOB |0 |UNDEF |erl_init_nothreads
% gcc -O2 -shared -fPIC app.c -L/usr/local/lib/erlang/lib/erl_interface-3.2/lib -lerl_interface -o app.so
% ls -l app.so
-rwxr-xr-x 1 per 124804 Mar 28 09:52 app.so
% nm app.so | grep erl_init_nothreads [187] | 7832| 24|FUNC |GLOB |0 |10 |erl_init_nothreads
>Your suggestion to recompile the Erlang libraries to shared ones sounds like the
>way forward to make the solution more seamless.
As I wrote, it has different properties: The shared object will be
smaller, but the erl_interface libraries have to be around - and
findable by the runtime linker - at runtime. The tradeoff isn't
clear-cut, it depends e.g. on what you intend to do with the shared
object distribution-wise.
--Per Hedeland
per@REDACTED
More information about the erlang-questions
mailing list