Thread: [tcljava-user] Seems to work on AMD64 Linux
Brought to you by:
mdejong
Menu
▾
▴
tcljava-user
|
From: Scott S. <ss...@am...> - 2005-10-14 03:49:14
|
After fiddling with tcljava.m4 I was able to get tclBlend to compile.
It's probably not as good as it could be, but it works and jtclsh gets
the right env too. (note that uname -m and $machine are "x86_64" not
"amd64" thats why the hard coded match)
I've never done m4 and I don't know much about autoconf, so hopefully
this work (sweat) helps someone or can be commited to CVS.
Thanks for all the work that goes into tclBlend,
-Scott
--------------------------
diff -Naur tclBlend1.3.2-old/tcljava.m4 tclBlend1.3.2-new/tcljava.m4
--- tclBlend1.3.2-old/tcljava.m4 2005-07-16 19:52:04.000000000 -0600
+++ tclBlend1.3.2-new/tcljava.m4 2005-10-13 21:41:11.000000000 -0600
@@ -924,6 +924,25 @@
fi
fi
+ # Sun JDK 1.5 for AMD64 Linux
+
+ F=jre/lib/amd64/libjava.so
+ if test "x$ac_java_jvm_jni_lib_flags" = "x" ; then
+ AC_MSG_LOG([Looking for $ac_java_jvm_dir/$F], 1)
+ if test -f $ac_java_jvm_dir/$F ; then
+ AC_MSG_LOG([Found $ac_java_jvm_dir/$F], 1)
+ D=`dirname $ac_java_jvm_dir/$F`
+ ac_java_jvm_jni_lib_runtime_path=$D
+ ac_java_jvm_jni_lib_flags="-L$D -ljava -lverify"
+ D=$ac_java_jvm_dir/jre/lib/amd64/server
+
ac_java_jvm_jni_lib_runtime_path="${ac_java_jvm_jni_lib_runtime_path}:$D"
+ ac_java_jvm_jni_lib_flags="$ac_java_jvm_jni_lib_flags
-L$D -ljvm"
+ D=$ac_java_jvm_dir/jre/lib/$machine/native_threads
+
ac_java_jvm_jni_lib_runtime_path="${ac_java_jvm_jni_lib_runtime_path}:$D"
+ ac_java_jvm_jni_lib_flags="$ac_java_jvm_jni_lib_flags -L$D"
+ fi
+ fi
+
# Blackdown JDK 1.1 for Linux (this one can get a little wacky)
F=README.linux
----------------------------
|
|
From: Mo D. <md...@un...> - 2005-10-14 09:44:49
|
On Thu, 13 Oct 2005 21:48:53 -0600 Scott Serr <ss...@am...> wrote: Hello Scott > After fiddling with tcljava.m4 I was able to get tclBlend to compile. > It's probably not as good as it could be, but it works and jtclsh gets > the right env too. (note that uname -m and $machine are "x86_64" not > "amd64" thats why the hard coded match) Nice work. It is really tricky keeping Tcl Blend working with all the wacky JVM configurations out there. > I've never done m4 and I don't know much about autoconf, so hopefully > this work (sweat) helps someone or can be commited to CVS. I just checked your patch into CVS. Could you check out the CVS version and double check that it works? One thing I noticed that I wanted to ask you about was the $JAVA/jre/lib/$machine/native_threads part. Does that actually resolve a library at link time or runtime? I was not sure from your patch if that was actually needed. If that dir is not actually used to resolve anything, then it would be better to remove it. cheers Mo DeJong |
|
From: Scott S. <ss...@am...> - 2005-10-14 13:51:45
|
Mo DeJong wrote: >On Thu, 13 Oct 2005 21:48:53 -0600 >Scott Serr <ss...@am...> wrote: > >Hello Scott > > > >>After fiddling with tcljava.m4 I was able to get tclBlend to compile. >>It's probably not as good as it could be, but it works and jtclsh gets >>the right env too. (note that uname -m and $machine are "x86_64" not >>"amd64" thats why the hard coded match) >> >> > >Nice work. It is really tricky keeping Tcl Blend working with all the >wacky JVM configurations out there. > > Thanks, I had no idea how wacky before visiting this file. > > >>I've never done m4 and I don't know much about autoconf, so hopefully >>this work (sweat) helps someone or can be commited to CVS. >> >> > >I just checked your patch into CVS. Could you check out the CVS version >and double check that it works? One thing I noticed that I wanted to >ask you about was the $JAVA/jre/lib/$machine/native_threads part. >Does that actually resolve a library at link time or runtime? I was not >sure from your patch if that was actually needed. If that dir is not actually >used to resolve anything, then it would be better to remove it. > > > You are right, I missed that "$machine" reference. It should be "amd64" or it should be taken out. Here is a question that might help resolve which way to go... I run tclsh and setup the environment manually much like jclsh does -- all in 32bit Linux. I noticed that I could leave out 2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" (as far as I know) TclBlend. One directory I could leave out for 32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads". Is this going to bite me later? or is "native_threads" not necessary? Trying to login to CVS... did this from 2 different hosts/networks and still no luck, I'll try later. # cvs -d:pserver:ano...@cv...:/cvsroot/tcljava login (Logging in to ano...@cv...) CVS password: cvs login: authorization failed: server cvs.sourceforge.net rejected access to /cvsroot/tcljava for user anonymous Thanks, Scott >cheers >Mo DeJong > > > |
|
From: Mo D. <md...@un...> - 2005-10-14 20:06:06
|
On Fri, 14 Oct 2005 07:51:03 -0600 Scott Serr <ss...@am...> wrote: > You are right, I missed that "$machine" reference. It should be "amd64" > or it should be taken out. Here is a question that might help resolve > which way to go... I run tclsh and setup the environment manually much > like jclsh does -- all in 32bit Linux. I noticed that I could leave out > 2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" > (as far as I know) TclBlend. One directory I could leave out for > 32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads". Is > this going to bite me later? or is "native_threads" not necessary? I took it out and checked into the CVS again. You would know if you needed the dir, since Tcl Blend would not load if it was missing. > Trying to login to CVS... did this from 2 different hosts/networks and > still no luck, I'll try later. Yeah, SF CVS can be a bit flaky sometimes. cheers Mo DeJong |
|
From: Scott S. <ss...@am...> - 2005-10-14 21:42:02
|
Mo DeJong wrote: >On Fri, 14 Oct 2005 07:51:03 -0600 >Scott Serr <ss...@am...> wrote: > > > >>You are right, I missed that "$machine" reference. It should be "amd64" >>or it should be taken out. Here is a question that might help resolve >>which way to go... I run tclsh and setup the environment manually much >>like jclsh does -- all in 32bit Linux. I noticed that I could leave out >>2 or 3 directories from the LD_LIBRARY_PATH and still have a "working" >>(as far as I know) TclBlend. One directory I could leave out for >>32bit/x86 Linux (with Sun JDK 1.5 atleast) was "native_threads". Is >>this going to bite me later? or is "native_threads" not necessary? >> >> > >I took it out and checked into the CVS again. You would know if you >needed the dir, since Tcl Blend would not load if it was missing. > > Oddly enough I just figured out what is in the native_threads. It is libhpi.so. (I forgot that) I removed the "-lhpi" and it compiles and apparently runs properly. So I guess we don't need hpi/native_threads? Maybe it's a legacy thing for a 1.3 or 1.4 x86 that we don't need to worry about in this instance. >>Trying to login to CVS... did this from 2 different hosts/networks and >>still no luck, I'll try later. >> >> > >Yeah, SF CVS can be a bit flaky sometimes. > > Thanks... I'll try again. |
|
From: Mo D. <md...@un...> - 2005-10-15 01:25:54
|
On Fri, 14 Oct 2005 15:41:56 -0600 Scott Serr <ss...@am...> wrote: > Oddly enough I just figured out what is in the native_threads. It is > libhpi.so. (I forgot that) I removed the "-lhpi" and it compiles and > apparently runs properly. So I guess we don't need hpi/native_threads? > Maybe it's a legacy thing for a 1.3 or 1.4 x86 that we don't need to > worry about in this instance. Well, the sure fire way to test this is to run "make test" from the Tcl Blend build dir. That will test normal loading and it will also test loading both Tcl Blend and Tcl into a JVM started from the java.exe process. In some cases, it may work when loaded into tclsh but not when both Tcl and TclBlend are loaded into Java. Just let me know if you run into any problems. cheers Mo DeJong |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X