Kenny Moens wrote: > I've tried both setups, i.e. with the JAR bundled and added to my > classpath, and manually put the DLLs in my java.library.path, both gave > the same issueS. Only if I include qtjambi.dll inside the PATH it seems > to go further, but then I get a JVM crash.
Need to get the unit tests working for you, so the soname "1" issue needs to be sorted for your setup. The crash reported is in a well tested piece of code using QApplication initialization. Also re the Windows DLL needing to be in the %PATH%. With Window platform (providing you don't tweak some Win32 system APIs, SetDllDirectory() or some such name, QtJambi currently doesn't) it will implicitly look in the same directory for the DLL it needs compared to the directory of the DLL being loaded. Since qtjambi.dll should be in the same directory as libcom_trolltech_qt_core.dll it should always be found. It is possible Win7 has patched some kind of change to not make that the default. It is possible also that this behaviour is driven based on the Win32 API version you build against. You can use the "Windows 7.1 SDK" on both WinXP and Win7 and it will default to the API level of the system it is running on at build time. I think you can tweak by passing "/winxp" argument. It is possible this might set the compatibility level of the resulting DLL and EXEs. This is the same kind of compatibility level used to get "Windows Live Messenger" on Win7 to go back to being a system tray icon instead of always in the task bar. You right click the application and set Compatibility tab to Windows Vista SP2, then restart the EXE and now it is a system tray icon again. So as another suggestion to look at maybe tweak in this area to see if you get a change of behaviour. If you manage to see a consistent change I am interested in to hear about this as it is something I have in TODO list for project to be able to start using SetDllDirectory() API correctly to increase application security (no DLL injection security concern). UPDATE from information gained when looking at my most recent Win32 builds. I have found time to take a look at Win32 x86 QtJambi builds (WinXP based) I make here from back in Jun 2012 using master commit-id 03a66f3 (same as you) has been successfully built and unit tested. So this is a useful fact to you, yes the tree you are having problems with has been tested and it works for at least one other person. My builds are built against Qt 4.7.4 (which is a local Qt build not one I downloaded). This is based on my tree at: SCM URL: http://git.gitorious.org/~dlmiles/qt/dlmiless-qt.git SCM branch: qtjambi-v4.7.4-4.7-20120307 SCM commit-id: 2f7459c7d02e3955379cf2223b1157de941f3d93 SCM comment: QtJambi: Qt Release qtjambi-v4.7.4-4.7-20120307 (v4.7.4+ branch 4.7 commit-id 95b6785) However it should not be necessary to use it, but I maintain a tree as to document tweaks and fixes relevant to Qt Jambi. You are using 4.8.x and a recent one at that (maybe from Digia not Nokia at that). So there maybe a change of policy. 4.8.x is known to work fine on Linux but I can not say when or if it has been tested on windows recently. My QtGui4.dll does have a transient dependency on SHELL32.DLL. On my build I also have missing IESHIMS.DLL (not bound). I do not have GPSVC.DLL listed at all. I have in addition WER.DLL that is also missing (on WinXP SP3 32bit). However I am not concerned as I think the functionality is dynamically bound at runtime via activation and the differences reflect changes in SHELL32.DLL which Microsoft would have managed backward compatibility of public APIs. In short this is internal implementation detail between platforms. So I my opinion this matter is not public API that I think affects Qt or Qt Jambi. My Qt Jambi DLLs do not have the "1" digit in the name. My build/qtjambi-*win32-msvc2010-*.jar has for example lib/com_trolltech_qt_gui.dll file inside. I did not do anything special during build to make that so. Obviously there maybe something I am doing and have forgotten about. But it means the problems you are reporting and crashes seem to be specific to your building environment and methods of working. Another factor is in using MSVC2010 and its environment setup (I am using Windows 7.1 SDK). Building under MSVC2010 instead of PSDK has been reported by others to work just fine (over the past 6 months). So some things to look at: In you "ant init.build" output check the reported value for: qtjambi.soname.version.major: <empty-string> (set blank by init) Note it is blank for me and this setting alters the "1", being blank results in unversioned DSOs. Consider unsetting the environment variable %VSINSTALLDIR% (so the side-by-side DLL operation is not attempted during packaging) and ignoring the warning you may now see. set VSINSTALLDIR= Check is disappears from "set" output. Consider sending (via private email) the following 3 things: - ZIPing up all your buildlogs in all your attempts (both failed and successful), maybe from file in buildlogs/* subdirectory but also stdout/stderr info if you have it. If you have already sent me info like this before please resend again. - Consider sending your "git diff ." from the top level directory so I can see all modifications that have been made on the tree. - Consider sending your environment variable outputs for "set" command from the cmd.exe shell you use to build. I am interested in improving the build but we have not gotten past the possibility there is something chronically wrong with your setup and methods of working that is contributing to the problems you are seeing. Please also stick with the current master commit-id 03a66f3 to work through the cause of the problem before upgrading to the current master. I going to revalidate Win32 builds over the next few weeks (after more WIP patches are pushed to master) but I shall be working from a known good state and I'm not expecting to encounter any problems. I hope this information is useful to help you establish what differences there are between your build setup and mine. It should also be useful to establish to you that the the master commit-id does work and unit test out-the-box on Win32 with MVC2010. Darryl As usual information is E&OE _______________________________________________ Qt-jambi-interest mailing list Qt-jambi-interest@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-jambi-interest
