Tcl/Tk

[Per Bohlin]

Hi again Magnus.

I don't know if I dare to put in an other theory here
but...

Could it be that the tcl library is not compiled to have position
independent code?
Since you should alreaddy have everything in there when runing tcl 
you could try to just remove -ltcl from your compilation command.

/Per Bohlin

Ljung Magnus wrote:
> 
> 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