Tcl/Tk

[Ljung Magnus]

Hi Per,

I tried the simple fix but could not get it to work. 
Get problems with the Tcl library:
gcc -O2 -shared -fPIC  app.c -I/EDUP/Tcl/0/include/ 
-I/EDUP/Otp/0/lib/erl_interface-3.2/include -L/EDUP/Tcl/0/lib  
-L/EDUP/Otp/0/lib/erl_interface-3.2/lib  \
 -lerl_interface -lei -lm -ltcl  -o app.so 
/EDUP/Tcl/0/lib/libtcl.a(tclAsync.o)
<unknown>                           0x180     	
/EDUP/Tcl/0/lib/libtcl.a(tclAsync.o)
<unknown>                           0x20      	
/EDUP/Tcl/0/lib/libtcl.a(tclAsync.o)
ld: fatal: relocations remain against allocatable but non-writable sections

You're probably correct that only my function call added in the Tcl source code 
will work but not the rest of the library functions...too bad.
Solaris 2.6 is the OS used and any help on how to make the Erlang libraries 
shared assuming available object code?

The application is for a Tcl/Tk program handling automatic tests of a Erlang 
node. This application adds a device package for the Network Elements so a 
configuration of the installation site is simpler than requiring a specific 
version of Tcl. Getting shared Erlang libraries would thus be better if there 
are no other solution.


//Magnus

P.S I do not subsrcibe to the mailing list yet so please send CC with the answer 
to me.

> To: etxmljg@REDACTED
> Subject: Re: Tcl/Tk
> Cc: erlang-questions@REDACTED
> Mime-Version: 1.0
> 
> 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