Ljung Magnus etxmljg@REDACTED
Tue Mar 28 08:39:24 CEST 2000

Hi Per & Per!

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. This is not the 
best solution but gives me the possibility to proceed until I find something 

I believe the theory of static linking is right on the money. I found a 
reference to a simular problem using shared libraries in Tcl.

Your suggestion to recompile the Erlang libraries to shared ones sounds like the 
way forward to make the solution more seamless.

Thanks // Magnus

> Subject: Re: Tcl/Tk
> To: Ljung Magnus <etxmljg@REDACTED>
> Cc: erlang-questions@REDACTED
> MIME-version: 1.0
> Content-transfer-encoding: 7bit
> X-Accept-Language: en
> Hi Magnus!
> I like the idea of what you are trying to do. It has some resemblance to
> what 
> I have done in GTE. The tool used to make the Motif user interfaces for 
> some element management systems at Ericsson.
> My theory about your problem is simply as follows.
> erl_interface and ei are only there for static linking.
> When you make a shared library, which you do, no linking is done.
> The -l flags you give only puts information in the library that 
> those libraries in theire turn should be loaded when your library is
> loaded.
> Thus you get no error when compiling.
> When running there is no erl_interface and ei to load so the first
> function
> in there that gets called fails. That first function would be erl_init 
> which is a macro defined to call erl_init_nothreads in your case.
> But this is just a theory. I only have experience of using the SUN
> Workshop
> compilers to make shared libraries. I think that would complain in the 
> compilation phase.
> If you have the source code you should be able to make shared library
> versions 
> of erl_interface and ei.
> Regards
> Per Bohlin
> Hm, you're doing some pretty complex stuff here, and I'm not sure your
> problems have much if anything to do with Erlang... - however the
> solution seems simple: Move the 'app.c' earlier in the commandline, such
> that it is before at least the '-L/.../erl_interface-3.2/lib
> -lerl_interface -lei' part - the linker needs to have processed the
> object produced from your app.c before it searches liberl_interface, in
> order to know that it should pull in from the library the object that
> satisfies the erl_init_nothreads reference (repeat for lots of other
> references in this case, but dlopen() only reports the first failure).
> That's why you generally have the library specifications towards the end
> of a linker commandline... - and if you weren't building a "shared
> object", you would have gotten the error at link time instead
> (presumably your successful build used a very different commandline),
> but since the reference may be satisfied at runtime in a way that the
> linker knows nothing about (e.g. through being defined in the binary
> that loads the object), it can't flag this as an error.
> Another solution (with different properties) would presumably be to
> build shared versions of libei and liberl_interface - this is left as an
> exercise for the reader...:-)
> --Per Hedeland
> PS If the -R option above means what I think it does (it's not in my gcc
> man page:-), i.e. runtime library search path, it's a no-op unless you
> have put some shared libraries of your own in that directory.
> Ljung Magnus wrote:
> > 
> > Hi!
> > 
> > I want to add an Erlang programming language interface to a Tcl/Tk
> > application. I'm using the erl_interface to C with the libraries libei.a
> > and liberl_interface.a. Compiling and inking a stand-alone application
> > C-Erlang works. When compiling a loadable package to Tcl/Tk adding a Tcl
> > command using one of the Erlang C library function something goes wrong.
> > Loading the shared library in tclsh I get the error:  relocation error:
> > file /home/etxmljg/application/app.o: symbol erl_init_nothreads:
> > referenced symbol not found
> > 
> > I guess this means that the runtime linker cant find the function in the
> > Erlang library. The result is the same for PTHREADS and STHREADS as
> > well. Is there any environment variable that I have missed or does it
> > depend on how the Erlang libraries have been compiled?
> > 
> > Compiler flags used:
> > gcc -O2 -shared -fPIC -R/EDUP/Otp/0/lib/erl_interface-3.2/lib
> > -I/EDUP/Tcl/0/include/ -L/EDUP/Tcl/0/lib
> > -I/EDUP/Otp/0/lib/erl_interface-3.2/include
> > -L/EDUP/Otp/0/lib/erl_interface-3.2/lib  \
> >  -lerl_interface -lei -lm -ltcl app.c -o
> > 
> > Regards // Magnus

More information about the erlang-questions mailing list