Hi Yarden,
It might be related to changes in gcc, sure. The compiler used
previously was gcc3.3. I notice there is a difference between -fpic and
-fPIC in the gcc docs, not sure if this is relevant to your platform. I
admit to knowing next to nothing about Linux so I can only comment and
not really give you a solution.
Looking at the grep you did, the undefined symbol was actually in the
library (along with another very simular symbol, any idea why?), so the
problem presumably is with Java linking with the library. I don't think
the fact the symbol in your standard Producer.so file is different is
relevant. It's a different lib and Producer::Camera will be different
because Producer::Referenced is derived from NoodleGlue::CBridgable.
One point about this link problem is that the app is not failing on the
first load of a library. Before Producer is loaded, the NoodleGlue lib
is loaded. Now, all library loads should be automatic through the
loadNativeLibrary calls which are part of all noodleglue class
contructors.This load consists of two steps:
1. The preload step which was added explicitly for Linux runtime
problems, which does dlopen(libName, RTLD_GLOBAL | RTLD_NOW) to
ensure the library is loaded with RTTI support (by default Java on
Linux doesn't support this fully, insane as this seems).
2. The basic java LoadLibrary which should not reload the library
again. The only user defined step here is a call to JNI_OnLoad function
per library to
register all classes with NoodleGlue, and this will only get called on
the loadLibrary calls.
Now I doubt is loadLibrary is literally reloading the lib, but maybe
some changes in gcc make the preload step invalid now. But really that
is as much info I can give you from a non-linux point of view.
On your other point, the classes NoodleGlue generates have no state, so
there is no need for virtual destructors. So the answer is yes, it's
deliberate.
bye for now
Tree
Yarden Livnat wrote:
Hi
I went back to the version with osg 0.98 and got the same problem. I
also checked and the -fPIC flag was used for all the compilations. I
wonder if this is related to gcc 4.0 . I'm also wondering why the
JavaOSG code does not define virtual destructor for classes that have
virtual functions ? was this done on purpose ?
thanks,
Yarden
tree wrote:
Hi Yarden,
It's true NoodleHeaven is no longer functioning as a company, so
those of us who previously worked there don't use OSG anymore. This is
pretty much why JavaOSG is fairly dormant, except for the recent
upgrade to osg 1.0. As I said before on this list, I am happy to help
fix up JavaOSG if I get feedback from users. I have avoided giving
JavaOSG to someone else to maintain because it relies on NoodleGlue
code generation, which I do still work on occasionally (I'm currently
adding function pointer support).
So to your point about OSG usage: We used to use OSG in Java for your
Noodle application and we also used it for some image processing tools.
It worked fine for us as far as we needed to use OSG, but that
admittedly was not far. But it included custom drawables and nodes
within various dynamic scenes, and our own visitors, and it worked
pretty well. The simple examples provided with JavaOSG show what you
can do as the simplest level and we used in a university course I
believe.
In regard to your linkage problem. I have a recollection the makefiles
which are currently provided with JavaOSG originally had a similar
problem, but the previous provider of makefiles (who may still be on
this list) fixed the problem. We certainly had a problem to do with the
global scope of symbols (between libraries) on Linux. Have you looked
at the previous makefiles as reference? The compiler flags might
provide a hint to fixing this (just had a quick look and I think it
might be the -fPIC compiler flag). I think by default with gcc on Linux
the symbols don't have global scope and have to be explicitly made so
for the compiler. I can't say more than that, as I only provided an
unpleasant Linux-only preloading phase for the JavaOSG libs, to avoid
the runtime implications of a related limitation with the Linux version
of Java. I can't say more as my email history was lost in a harddrive
failure.
Oh and if you are happy to fix up the makefiles I'm happy to put them
into the releases of JavaOSG if you like.
BTW, as I don't really read this list very often if you want more
support or have contributions on JavaOSG is it best to contact me
directly as noodleglue (at) noodleheaven.net. Thanks Andreas for
pointing out this message.
Bye now,
Tree
Message: 7
Date: Tue, 02 May 2006 15:57:36 -0600
From: Yarden Livnat <[EMAIL PROTECTED]>
Subject: [osg-users] Java binding
To: osg users <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I've used osg for many years but now I need a good scene graph for a
Java project I'm working on. The sad story is that the status Java
based scene graph is rather dismal. Maybe I'm spoiled by the quality of
osg :-) I've checked jME, Xith3d, j3d and Aviatrix3D.
I thus came back to osg and looked for Java bindings.
1. josgviewer does not seem to be more than an example. One need a
handwritten wrapper for each C++ class used from Java.
2. JavaOSG. I had high hopes for this one but alas NoodleHeaven seems
to be out of business. My major problem here is that the code does not
work on Linux, though as promised it does work on Windows.
In the past I've seen some posts regarding JavaOSG and I wonder whether
anyone had any luck with it ? What is your experience with this
technology either in development or runtime ? are there any known
issues in Windows or Linux (well a part from the fact that right now it
has some strange issues with undefined symbols, see bellow).
I'll be happy to put the effort to try and get JavaOSG back on its feet
(or any other good solution) as well as post any info, insight or hints
I collect. However, the project I work on can not wait for much longer
before it will switch to one of the other java based scenegraph (which
will be a shame).
thanks !
Yarden Livnat
Research Scientist
SCI Institute, University of Utah
p.s
The Linux issue , at least in my case, is that the c++ binding in
JavaOSG generate name signatures that are slightly different then the
ones generates in the original osg.
for example: (note, the program compiles fine)
======================================
[EMAIL PROTECTED]> java openscenegraph.examples.OsgGeometry
Exception in thread "main" java.lang.UnsatisfiedLinkError:
/opt/java/lib/libJavaProducer.so: /opt/java/lib/libJavaProducer.so:
undefined symbol: _ZThn24_N8Producer6Camera3runEv
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at
noodle.noodleGlue.library.ProducerJNILibrary.loadNativeLibrary(Unknown
Source)
at producer.Referenced.<clinit>(Unknown Source)
at openscenegraph.examples.OsgGeometry.main(Unknown Source)
// checking for the missing symbol in the java/c++ binding
[EMAIL PROTECTED] > nm /opt/java/lib/libJavaProducer.so | grep
N8Producer6Camera3runEv
U _ZN8Producer6Camera3runEv
U _ZThn24_N8Producer6Camera3runEv
// but the name is different in original osg ... (note the n24_ in the
above and n8_ bellow.
// I can't figure out what they mean and c++filt seems to ignore them
all together
[EMAIL PROTECTED]> nm /usr/local/lib/libProducer.so | grep
N8Producer6Camera3runEv
00027c04 T _ZN8Producer6Camera3runEv
0002bd7c W _ZThn8_N8Producer6Camera3runEv
=======================================
again, any insight into this issue or into the whole issue of Java
access to OSG will be greatly appreciated.
Yarden
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
|
