Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-jambi-interest Archive, June 2007
JDK 6 supported?

Message 1 in thread

Hi!

I saw the someone else has reported the same or similar error with version 
6 of the Java SDK:

$ LD_LIBRARY_PATH= ./qtjambi.sh
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_initLibrary()V
         at 
com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_initLibrary(Native 
Method)
         at 
com.trolltech.qt.core.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:10)
         at 
com.trolltech.qt.core.QAbstractFileEngineHandler.<clinit>(QAbstractFileEngineHandler.java:12)
         at 
com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:24)
         at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:29)


Is this version supported in general? Setup issue on my side? I wonder 
what kinds of environment variables might still be required. "java" is in 
PATH.

Harri.
Message 2 in thread

> Is this version supported in general? Setup issue on my side? I wonder
> what kinds of environment variables might still be required. "java" is in
> PATH.

Thus far I've found that no matter where you put the shared libraries, you still
have to point LD_LIBRARY_PATH to that directory (that includes the Qt library
directory, and even /usr/lib, both of which are registered with the dynamic linker
in ld.so.conf).

Caleb
Message 3 in thread

Caleb Tennis wrote:
>>Is this version supported in general? Setup issue on my side? I wonder
>>what kinds of environment variables might still be required. "java" is in
>>PATH.
> 
> 
> Thus far I've found that no matter where you put the shared libraries, you still
> have to point LD_LIBRARY_PATH to that directory (that includes the Qt library
> directory, and even /usr/lib, both of which are registered with the dynamic linker
> in ld.so.conf).

And this is also true for the last versions? Where does it fail when you 
only specify classpath (preferably with 
-Dcom.trolltech.qt.verbose-loading to see full details)?

-
Gunnar
Message 4 in thread

> And this is also true for the last versions? Where does it fail when you
> only specify classpath (preferably with
> -Dcom.trolltech.qt.verbose-loading to see full details)?

I've been playing around for where I want the shared libraries to go.  As of now
I've put them in the same directory that Qt4 is installed (/usr/lib/qt4).  This
directory is part of my ld path (ie, defined in ld.so.conf and searched by the
dynamic linker).  Originally I had them installed in /usr/lib, but it gives the same
results.  I've rerun ldconfig as well.


Trying to start like this:


java -Dcom.trolltech.qt.verbose-loading=true -cp
/usr/share/qtjambi-4/lib/qtjambi.jar com.trolltech.launcher.Launcher


gives:


No 'qt_system_libs' file

Going to load: libQtCore.so.4
java.lang.RuntimeException: Library: 'libQtCore.so.4' could not be resolved
        at com.trolltech.qt.Utilities.loadLibrary(Utilities.java:178)
        at com.trolltech.qt.Utilities.loadQtLibrary(Utilities.java:127)
        at
com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:31)
        at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:40)
java.lang.UnsatisfiedLinkError: no QtCore in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:993)
        at com.trolltech.qt.Utilities.loadLibrary(Utilities.java:225)
        at com.trolltech.qt.Utilities.loadQtLibrary(Utilities.java:127)
        at
com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:31)
        at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:40)
Failed to find libQtCore.so.4 in
/opt/sun-jdk-1.5.0.11/jre/lib/i386/client:/opt/sun-jdk-1.5.0.11/jre/lib/i386:/opt/sun-jdk-1.5.0.11/jre/../lib/i386:/g4/lib
Loading: libQtCore.so.4 failed.

...
repeat for libQtGui.so.4, libqtjambi.so, and libcom_trolltech_qt_core.so
...

Exception in thread "main" java.lang.UnsatisfiedLinkError: __qt_initLibrary

        at com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_initLibrary(Native
Method)
        at
com.trolltech.qt.core.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:10)
        at
com.trolltech.qt.core.QAbstractFileEngineHandler.<clinit>(QAbstractFileEngineHandler.java:10)
        at
com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryInitializer.java:35)
        at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:40)

--------

However, starting it like this:

tc@tc12 ~ $ LD_LIBRARY_PATH=/usr/lib/qt4 java -cp
/usr/share/qtjambi-4/lib/qtjambi.jar com.trolltech.launcher.Launcher

Works just fine.
Message 5 in thread

Caleb Tennis wrote:
>> And this is also true for the last versions? Where does it fail when you
>> only specify classpath (preferably with
>> -Dcom.trolltech.qt.verbose-loading to see full details)?
> 
> I've been playing around for where I want the shared libraries to go.  As of now
> I've put them in the same directory that Qt4 is installed (/usr/lib/qt4).  This
> directory is part of my ld path (ie, defined in ld.so.conf and searched by the
> dynamic linker).  Originally I had them installed in /usr/lib, but it gives the same
> results.  I've rerun ldconfig as well.

But if you keep them in the location they are when you just unpack the 
package. e.g:

/qtjambi-linux32-gpl-4.3.0_01/qtjambi.jar
/qtjambi-linux32-gpl-4.3.0_01/lib/libQtCore.4.so
/qtjambi-linux32-gpl-4.3.0_01/lib/libqtjambi.so
etc...

Does it work then?

-
Gunnar
Message 6 in thread

> And this is also true for the last versions? Where does it fail when you

Also, yes, this is for the downloaded 4.3.0_01 (unless it's been updated since the
day it was released).

Caleb
Message 7 in thread

Harri Porten wrote:
> Hi!
> 
> I saw the someone else has reported the same or similar error with 
> version 6 of the Java SDK:
> 
> $ LD_LIBRARY_PATH= ./qtjambi.sh
> Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_initLibrary()V
...
> 
> Is this version supported in general? Setup issue on my side? I wonder 
> what kinds of environment variables might still be required. "java" is 
> in PATH.

Hi Harri,

Qt Jambi searches for shared libraries relative to the qtjambi.jar file, 
  in the subfolder /lib spesifically. By just putting qtjambi.jar into 
you classpath it should load just fine.

When this is not the case it may be because of some broken dependency. 
We still rely on Xinerama, Xlib and some other basic libraries to be 
present on the system. If these are not there it will fail to load. You 
can debug a bit further by adding -Dcom.trolltech.qt.verbose-loading to 
the java command line.

e.g:

java -Dcom.trolltech.qt.verbose-loading -cp qtjambi.jar 
com.trolltech.launcher.Launcher

That will tell you a bit more as to which libraries are being loaded and 
where they might fail.

-
Gunnar
Message 8 in thread

Hello Gunnar,

On Wed, 13 Jun 2007, Gunnar Sletta wrote:

> When this is not the case it may be because of some broken dependency. We 
> still rely on Xinerama, Xlib and some other basic libraries to be present on 
> the system. If these are not there it will fail to load. You can debug a bit 
> further by adding -Dcom.trolltech.qt.verbose-loading to the java command 
> line.

libXinerama.so is indeed the problem. My system only has a .a version 
which seems typical for slightly older X11 versions. Can't you link 
statically, too?

My solution: copied Qt libraries I build by own into lib/ and created a 
fake libXinerama.so.1 library by renaming another library without further 
deps.

Thanks for the hint about the verbose-loading switch.

Harri.
Message 9 in thread

On Wednesday 13 June 2007 21:05:49 Harri Porten wrote:
> Hello Gunnar,
>
> On Wed, 13 Jun 2007, Gunnar Sletta wrote:
> > When this is not the case it may be because of some broken dependency. We
> > still rely on Xinerama, Xlib and some other basic libraries to be present
> > on the system. If these are not there it will fail to load. You can debug
> > a bit further by adding -Dcom.trolltech.qt.verbose-loading to the java
> > command line.
>
> libXinerama.so is indeed the problem. My system only has a .a version
> which seems typical for slightly older X11 versions. Can't you link
> statically, too?

On such installations I believe it is very likely that the code in 
libXinerama.a is not compiled position independent. Linking that into a 
shared object is IMHO something we should really avoid (besides all the 
limitations it brings along).

Simon

Attachment:

Attachment: signature.asc
Description: This is a digitally signed message part.

Message 10 in thread

Hi!

I reported success too early. Exchanged the Qt libraries with my own 
caused undefined symbol error laters. Is Jambi using Qt 4.3.0 final? Hmmm. 
Maybe I should double check that I wasn't a pre-release version.

On Thu, 14 Jun 2007, Simon Hausmann wrote:

>> libXinerama.so is indeed the problem. My system only has a .a version
>> which seems typical for slightly older X11 versions. Can't you link
>> statically, too?
>
> On such installations I believe it is very likely that the code in
> libXinerama.a is not compiled position independent. Linking that into a
> shared object is IMHO something we should really avoid (besides all the
> limitations it brings along).

And how about compiling your own PIC version of it? Or is there a 
dependency on the X11 version which could cause a conflict?

Harri.
Message 11 in thread

On Thursday 14 June 2007 10:40:05 Harri Porten wrote:
[...]
> On Thu, 14 Jun 2007, Simon Hausmann wrote:
> >> libXinerama.so is indeed the problem. My system only has a .a version
> >> which seems typical for slightly older X11 versions. Can't you link
> >> statically, too?
> >
> > On such installations I believe it is very likely that the code in
> > libXinerama.a is not compiled position independent. Linking that into a
> > shared object is IMHO something we should really avoid (besides all the
> > limitations it brings along).
>
> And how about compiling your own PIC version of it? Or is there a
> dependency on the X11 version which could cause a conflict?

For building libXinerama you have to use the X.org libraries (configure.ac of 
libXinerama in X.org looks for x11.pc, xext.pc). As much as I trust X.org 
binary compatibility I don't think it's worth the risk of compiling against 
X.org headers but dynamically linking the app against older xlibs.


Simon

Attachment:

Attachment: signature.asc
Description: This is a digitally signed message part.

Message 12 in thread

On Wed, 13 Jun 2007, Gunnar Sletta wrote:

> Qt Jambi searches for shared libraries relative to the qtjambi.jar file,  in 
> the subfolder /lib spesifically. By just putting qtjambi.jar into you 
> classpath it should load just fine.

What if I do not have a .jar file but only the .class file structure in 
com/trolltech? Does the same rule apply?

I think I had to set LD_LIBRARY_PATH= to the lib/ directory even with the 
binary package and other odd effects when playing around with libraries. I 
somehow have the feeling that something is fishy with the lookup 
mechanism.

Harri.
Message 13 in thread

On Thursday 14 June 2007 18:29, Harri Porten wrote:
> On Wed, 13 Jun 2007, Gunnar Sletta wrote:
> > Qt Jambi searches for shared libraries relative to the qtjambi.jar file, 
> > in the subfolder /lib spesifically. By just putting qtjambi.jar into you
> > classpath it should load just fine.
>
> What if I do not have a .jar file but only the .class file structure in
> com/trolltech? Does the same rule apply?
>
> I think I had to set LD_LIBRARY_PATH= to the lib/ directory even with the
> binary package and other odd effects when playing around with libraries. I
> somehow have the feeling that something is fishy with the lookup
> mechanism.
>
> Harri.

Hi,

The same thing apply if you don't have a jar file. So your lib folder needs to 
be relative to the com.trolltec.qt... structure.

If your lib folder only contains the Qt Jambi libraries then you will need to 
make sure that the correct Qt libraries is in your path (LD_LIBRARY_PATH), or 
specify it using -Djava.library.path.

You can also copy the Qt libs into the lib folder as we have done with the 
binary distributions of Qt Jambi.

The look-up mechanism search for the libraries in this order:

1.   Looking in com.trolltech.qt.library-path
2.   Looking in com.trolltech.qt.internal.jambipath (used internally)
3.   Looking in your classpath, including jar files
4.   Relative loading (relative to qtjambi.jar or root of package structure.) 
5.   Looking in java.library.path (same as LD_LIBRARY_PATH)

And to help you debug, try setting -Dcom.trolltech.qt.verbose-loading, this 
will print out some information when the libraries are loaded. (or not 
loaded :-))

Best regards
	Håvard Frøiland
Message 14 in thread

Hello,

$ java -version
java version "1.6.0"
---
$ cat ~/.bashrc
---
CLASSPATH=/opt/classesJava/qtjambi.jar:$CLASSPATH
export CLASSPATH
LD_LIBRARY_PATH=/usr/local/QtJambi/qtjambi-linux32-gpl-4.3.0_01/lib
export LD_LIBRARY_PATH
QT_PLUGIN_PATH=/usr/local/QtJambi/qtjambi-linux32-gpl-4.3.0_01/plugins
export QT_PLUGIN_PATH
---

OK,

A+,

Claude
Message 15 in thread

Hello,

Home with qtjambi-linux32-gpl-4.3.0_01.tar.gz:

$ echo $LD_LIBRARY_PATH
/usr/local/QtJambi/qtjambi-linux32-gpl-4.3.0_01/lib

$ java COM/trolltech/examples/… // OK

A+,

Claude.