tcljava-user

[tcljava-user] loading .so in Tcl that is created from Java

[Scott S. <ss...@am...>]

Hello Tcl Blenders,

We are able to use TclBlend to create a (real, not Jacl) Tcl interpreter 
from Java.  We have LD_LIBRARY_PATH set.  We eval a 'load foo.so' in 
Tcl.  This works, but foo.so is supposed to automatically load bar.so... 
it doesn't.

We are using Linux with Sun JDK 1.5.0_06.  My cube-mate read that in 
general Java didn't use the standard link loader.  It even goes on to 
say that automatic secondary loading might or might not happen.

In short...

Tcl starting the JVM,  Tcl "load foo.so" also loads "bar.so" for us.

JVM starting the Tcl Interpreter, Tcl "load foo.so" succeeds but fails 
to load bar.so and has un resolved dependencies.

Any ideas of how to solve this?  We thought about combining our dozen or 
so *.so files into one...  We can't figure out how to do this after the 
fact, pretending we can't do this at compile time by combining the .o 
files.  Reason is:  1. vendor doesn't support this.  2. the build is a 
complex mess that builds .o files in a bazillion directories.... who 
knows which ones we need and if we can do it right.

Anyone have this problem?  Anyone fix it?

Thanks!
Scott

Re: [tcljava-user] loading .so in Tcl that is created from Java

[Mo D. <md...@un...>]

On Thu, 23 Mar 2006 17:30:20 -0700
Scott Serr <ss...@am...> wrote:

> Hello Tcl Blenders,
> 
> We are able to use TclBlend to create a (real, not Jacl) Tcl interpreter

I will pretend you did not say that :)

> from Java.  We have LD_LIBRARY_PATH set.  We eval a 'load foo.so' in 
> Tcl.  This works, but foo.so is supposed to automatically load bar.so... 
> it doesn't.

Well, first you should check the shared library to make sure the other
shared libs it depends on are linked in. Exactly how you do that depends
on the OS, but with Linux you should be able to use ldd. Sometimes
the shared libs are not built properly and only the executables actually
link in all the shared libs that are needed.

> We are using Linux with Sun JDK 1.5.0_06.  My cube-mate read that in 
> general Java didn't use the standard link loader.  It even goes on to 
> say that automatic secondary loading might or might not happen.
> 
> In short...
> 
> Tcl starting the JVM,  Tcl "load foo.so" also loads "bar.so" for us.
> 
> JVM starting the Tcl Interpreter, Tcl "load foo.so" succeeds but fails 
> to load bar.so and has un resolved dependencies.
> 
> Any ideas of how to solve this?  We thought about combining our dozen or 
> so *.so files into one...

Humm, another approach you can try is just loading the other
shared libs before you load the one with the deps. Running load Tcl command
with an empty string as the init method will raise an error, but it does
do the OS load behind the scenes. I would give that a try and see if
it fixes things before trying to rebuild libraries.

I hope that helps
Mo DeJong

Re: [tcljava-user] loading .so in Tcl that is created from Java

[Scott S. <ss...@am...>]

On 03/23/06 20:37, Mo DeJong wrote:

>On Thu, 23 Mar 2006 17:30:20 -0700
>Scott Serr <ss...@am...> wrote:
>  
>
>>Hello Tcl Blenders,
>>
>>We are able to use TclBlend to create a (real, not Jacl) Tcl interpreter
>>    
>>
>
>I will pretend you did not say that :)
>  
>
I should have clarified the need to clarify.  We were doing new 
tcl.lang.Interp() and where using Jacl unknowingly because it was in our 
CLASSPATH first?

I read through the mailing list and you seemed to imply Jacl would not 
allow for the Tcl "load" command.  I did notice when we were 
"accidently" using it, that it seemed to not inherit environment 
variables in $env/$::env.  So setting up LD_LIBRARY_PATH wasn't an 
option.  Is this normal?  Am I way out there?

>>Tcl starting the JVM,  Tcl "load foo.so" also loads "bar.so" for us.
>>
>>JVM starting the Tcl Interpreter, Tcl "load foo.so" succeeds but fails 
>>to load bar.so and has un resolved dependencies.
>>
>>Any ideas of how to solve this?  We thought about combining our dozen or 
>>so *.so files into one...
>>    
>>
>
>Humm, another approach you can try is just loading the other
>shared libs before you load the one with the deps. Running load Tcl command
>with an empty string as the init method will raise an error, but it does
>do the OS load behind the scenes. I would give that a try and see if
>it fixes things before trying to rebuild libraries.
>
>I hope that helps
>Mo DeJong
>  
>
We will try that...  I guess ldd will show us what order to try to load 
them in.  Thanks Mo!  You and TclBlend are great, excellent work!  
Without it we would have to be writing large (steaming) piles of C++ 
instead of (fresh) cart-loads of Java.  And TclBlend is so much easier 
than calling C++ from Tcl, unless I totally missed something. :)

Thanks,
Scott Serr