Qt-jambi-interest Archive, September 2007
Switching target host on Windows XP
Message 1 in thread
I'm trying to setup a demo, but when I try to pack everything in a single
zip and unzip them on another machine than my developer machine, with jambi
in a separate directory (just like it's beeing downloaded from TrollTech, I
encounter the stack below. I thought it was due to java not beeing able to
find the binaries, but it didn't help much putting the dll files in a
directory pointed to by the PATH. Any ideas? Some system dll's missing which
I might have on my developer machine because of my Visual Studio
installation or something strange like that?
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(Nat
ive Method)
at com.trolltech.qt.core.QtJambi_LibraryInitializer.<clinit>(QtJambi_Lib
raryInitializer.java:10)
at com.trolltech.qt.core.QAbstractFileEngineHandler.<clinit>(QAbstractFi
leEngineHandler.java:10)
at com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryI
nitializer.java:24)
at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:29)
at com.poseidon.simulation.standalone.VhfClient.main(VhfClient.java:23)
c:\radio-holland-stand-alone\bin>client.bat
Exception in thread "main" java.lang.UnsatisfiedLinkError:
com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_i
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:24)
at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:29)
Regards,
Helge Fredriksen
Message 2 in thread
Helge Fredriksen wrote:
> I'm trying to setup a demo, but when I try to pack everything in a single
> zip and unzip them on another machine than my developer machine, with jambi
> in a separate directory (just like it's beeing downloaded from TrollTech, I
> encounter the stack below. I thought it was due to java not beeing able to
> find the binaries, but it didn't help much putting the dll files in a
> directory pointed to by the PATH. Any ideas? Some system dll's missing which
> I might have on my developer machine because of my Visual Studio
> installation or something strange like that?
Hi Helge,
All the dll's that we depend on should be in the package. For the
commercial package, this should be msvcr80.dll and msvcp80.dll. If you
moved Qt Jambi to another machine that didn't have Visual Studio
installed you have to make sure that these are available in PATH or
already installed on the machine.
see:
http://doc.trolltech.com/qtjambi-4.3.1_01/com/trolltech/qt/qtjambi-deployment.html
Unlike the other libraries we ship, like qtjambi.dll and QtCore4.dll the
msvc runtimes are not explicitly loaded by the binary package, so you
actually need to have them in your path...
The easiest thing is probably to bundle all the libraries into a .jar
file and use the "qt_system_libs" as described in the package. You can
of course also sneak a peek on webstart binaries to see how its solved
in practice.
see:
http://dist.trolltech.com/developer/download/webstart/qtjambi-win32-gpl-4.3.1_01.jar
hope this helps,
Gunnar
> 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(Nat
> ive Method)
> at com.trolltech.qt.core.QtJambi_LibraryInitializer.<clinit>(QtJambi_Lib
> raryInitializer.java:10)
> at com.trolltech.qt.core.QAbstractFileEngineHandler.<clinit>(QAbstractFi
> leEngineHandler.java:10)
> at com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(QtJambi_LibraryI
> nitializer.java:24)
> at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:29)
> at com.poseidon.simulation.standalone.VhfClient.main(VhfClient.java:23)
> c:\radio-holland-stand-alone\bin>client.bat
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_i
> 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:24)
> at com.trolltech.qt.QtJambiObject.<clinit>(QtJambiObject.java:29)
>
> Regards,
> Helge Fredriksen
>
Message 3 in thread
> Hi Helge,
>
> All the dll's that we depend on should be in the package. For the
> commercial package, this should be msvcr80.dll and msvcp80.dll. If you
> moved Qt Jambi to another machine that didn't have Visual Studio
> installed you have to make sure that these are available in PATH or
> already installed on the machine.
>
> see:
> http://doc.trolltech.com/qtjambi-4.3.1_01/com/trolltech/qt/qtjambi-deployment.html
>
>
> Unlike the other libraries we ship, like qtjambi.dll and QtCore4.dll
> the msvc runtimes are not explicitly loaded by the binary package, so
> you actually need to have them in your path...
Hmmm, tried to copy them to c:\windows\system32 without much luck. Same
error message appearing still.
>
> The easiest thing is probably to bundle all the libraries into a .jar
> file and use the "qt_system_libs" as described in the package. You can
> of course also sneak a peek on webstart binaries to see how its solved
> in practice.
A bit more eleborate deploying process than I had hoped for, though. If
would like to keep the "separate jambi dir" approach instead of using
executable jar, where in the file tree should we put the qt_system_libs
file?
Regards,
Helge Fredriksen
Message 4 in thread
Helge Fredriksen wrote:
>> Hi Helge,
>>
>> All the dll's that we depend on should be in the package. For the
>> commercial package, this should be msvcr80.dll and msvcp80.dll. If you
>> moved Qt Jambi to another machine that didn't have Visual Studio
>> installed you have to make sure that these are available in PATH or
>> already installed on the machine.
>>
>> see:
>> http://doc.trolltech.com/qtjambi-4.3.1_01/com/trolltech/qt/qtjambi-deployment.html
>>
>>
>> Unlike the other libraries we ship, like qtjambi.dll and QtCore4.dll
>> the msvc runtimes are not explicitly loaded by the binary package, so
>> you actually need to have them in your path...
>
> Hmmm, tried to copy them to c:\windows\system32 without much luck. Same
> error message appearing still.
Its a good idea to never put anything in c:\windows\system32, especially
now that microsoft is moving to manifests based deployment.
>> The easiest thing is probably to bundle all the libraries into a .jar
>> file and use the "qt_system_libs" as described in the package. You can
>> of course also sneak a peek on webstart binaries to see how its solved
>> in practice.
> A bit more eleborate deploying process than I had hoped for, though. If
> would like to keep the "separate jambi dir" approach instead of using
> executable jar, where in the file tree should we put the qt_system_libs
> file?
qt_system_libs needs to be in the classpath root. What I aimed at here
was that you create two .jar files, non of which are made executable.
The first one contains.
./qt_system_libs
./qtjambi.dll
./com_trolltech_qt_core.dll
etc...
The other one contains the classes.
If you put both of these in our classpath it will load _exactly_ like
the webstart does, which is why I pointed you to the webstart .jar file
because it shows the exact structure the .jar file should have.
You can of course put all into one .jar file, but its nice to keep the
classes and the binaries separate, I think.
If it still doesn't load, could you please give me some more details on
which config/setup you have here? windows version, verbose-loading
output, etc?
best regards,
Gunnar
