NOTE: I have also read your other email with the patch to the file src/java/qtjambi/com/trolltech/qt/internal/NativeLibraryManager.java.
However from my point of view the question has never been where in the QtJambi source is this number getting in (I know that). But why is your build getting a "1" instead of a null or "" blank string. Especially when your reply points that the build configuration setting for: qtjambi.soname.version.major: <empty-string> (set blank by init) An <empty-string> is not a string containing a character of the number one "1". Understanding this will allow a proper fix to be looked at. So if you work through that code again an version="" then what is the resulting DLL files name ? Re the attachments, you need to delete the qtjami1.dll and any DLL you copied in this way com_trolltech_qt_core1.dll and com_trolltech_qt_gui1.dll and com_trolltech_qt_opengl1.dll. This is only going to interfere with the results. All testing presumes you did not modify the Qt Jambi elements in this way the DLL files you deploy should be the same as those found in build/platform-output*/lib/ directory. If you need to rebuild the original state of this directory, you can deleted build/platform-output* and then re-run 'ant library examples' to cause it to be rebuilt. Also have you tried cleaning the project "ant distclean" and rebuilding from scratch. The further replies below attempt to work through to that cause of the real problem, the patch you have created is not a fix. Kenny Moens wrote: > On 01/11/2012 20:13, Darryl Miles wrote: >> 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. > I've just managed to run the unit tests (ant targets tests.compile and > then tests.run). The result of this is that I have a success rate of > 98.16%, which is obviously not that good. This is good and the pass % I'd expect. Proves that the build you have created does run ok when presented with the right runtime environment. This is also good as it means that if the unit tests are working for you then the soname "1" issue only affects running a real application and not the unit tests. So I should look beyond unit tests at this problem. This means I go back to my build of 03a66f3 on WinXP (which I still have untouched since June) and try running some applications, then establish why unit tests do not pick up the problem. ... The QtJambi project does need "Integration Tests" for just this kind of thing, testing deployment scenarios, but it does not have any at this time. Hence it is easy to break another right now. I did do a version of QtJambi project entirely in Maven (which can address some of these matters better than ANT) but it was not compellingly better (due to being mixed C/C++/Java project). For a 100% Java project Maven is a no-brainer right now. I am currently doing work with the 'gradle' build tool to good effect, all for the things I'd wished for with Maven seem to be possible and much of Maven conversion work, modules/plugins and ANT elements can be either reused as-is or reworked/improved upon. But it will be another 3 months before I seriously consider converting Qt Jambi, I am still learning aspects of it on a project that is similar and much smaller scale. > The problematic areas are: > > * com.trolltech.autotests.TestClipboard <3_TestClipboard.html>, > TestStartup : No Runnable Methods This is a new / recent test I added, it is disabled as it io known to be broken on Windows at least. It relates to verifying the fix for the work on bug#114. A fix has been applied that worked for Linux but the unit test still crashes on windows. Some more work is needed still. > * some related to memory management, which complain that my Qt Jambi > is not build with "QTJAMBI_DEBUG_TOOLS" This is normal, some tests require QtJambi to be built with additional memory management overhead. These tests are skipped. You don't really need to run them as we don't suspect an issue int he areas they test. I just wanted to keep feedback about how healthy your build is. > * com.trolltech.autotests.TestVirtualFunctions: assertion error on > TestVirtualFunctions line 407 Interestingly I am seeing this problem on ARM Raspberry Pi. I think it has something to do with imageformat plugin enumeration since when touching the QIcon. From memory I don't think Linux has an error here but will be checking as I investigate it. > * com.trolltech.unittests.TestQSslSocket: all of them are failing This is probably due to not having the 2 OpenSSL libraries available. It depends if you want/need HTTPS support from Qt APIs. In your "ant init.build" section look at the settings for: [qtjambi-initialize-build] qtjambi.packaging.dso.libeay32: <notset> [qtjambi-initialize-build] qtjambi.packaging.dso.libssl: <notset> [qtjambi-initialize-build] qtjambi.packaging.dso.libcrypto: <notset> [qtjambi-initialize-build] qtjambi.packaging.dso.libz: <notset> also confirm the DLLs were copied into the native JAR and are also present in your download of Qt. Can you also confirm the settings you see for the above and exact filenames you get in the Qt I have not checked 4.8.x on windows. The point of this test is to verify this common problem (why doesn't HTTPS work) because the OpenSSL parts were no packaged and made available. Maybe setting %PATH% also fixes this problem for you ? >> 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. > From what I gathered from some searches on Google is that this behavior > is inherit due the way Java loads the JNI libraries. If I recall > correctly it is because Java uses LoadLibrary instead of LoadLibraryEx. > However I'm not an expert on Windows programming though. No. Your statement is correct for the loading of libcom_trolltech_qt_core.dll which is loaded with Java API System.loadLibrary() that as your research has found called the OS system API LoadLibrary. From memory we always provide a full absolute path to the DLL so there is never any problem knowing exactly which DLL file on the file system is being loaded. There is also never any problem finding the DLL since there is no need for the operating system to "search" for it. But your issue is not with the loading of libcom_trolltech_qt_core.dll but with the implicit (or transient) loading of qtjambi.dll that libcom_trolltech_qt_core.dll depends on. Not finding it of course can make the error to appear to be with libcom_trolltech_qt_core.dll. The mechanism to load these transient DLLs is what is influenzed by %PATH% and by SetDllDirectory system API call. There is a page somewhere discussing how DLL searching varies between windows system due to improvements in security. If you search on MSDN for SetDllDirectory you will find. Transient DLLs that are not already loaded follow the rules for "searching". Now it maybe possible for the QtJambi to pre-load qtjambi.dll or use SetDllDirectory() but that is a topic for me to get to in the future with some proper research and experimentation. For now your fastest fix is just to add the lib/ directory to the %PATH% before running your application. Since you are using Java you probably already have some kind of wrapper in place, i.e. you don't run java.exe directly but maybe a *.bat or another EXE that is a Java wrapper. This wrapper is what you put on your desktop and in your Start menu icon. So controlling the %PATH% before executing Java should be possible for you. > It seems to give the same issues if I run it in compability mode. I > still get the JVM crash which I send out earlier. This was more a suggestion. My talk of /winxp switch (which I meant to say /xp) was for the Windows Platform SDK 7.1 and the setenv.bat takes the switches like "/xp /x86 /release". When you run it you get a cmd.exe window open and it will say: Setting SDK environment relative to C:\Program Files\Microsoft SDKs\Windows\v7.1\. Targetting Windows 7 x86 Release C:\Program Files\Microsoft SDKs\Windows\v7.1> Note the "Targetting Windows 7" part. This changes at least the %TARGET_PLATFORM% environment variable from WIN7 to XP. Maybe it changes other things I'm not sure. This can affect the available APIs an the resulting compatibility modes set in the EXE/DLLs that could be affecting behavior. Maybe VS2010 has a way as well. > Indeed. Still, my unit tests seem to give quite good results too, most > of the failing parts are not related to anything I see at runtime, as > there I mainly see a JVM crash. While when running the unit tests, I saw > sometimes a window popping up correctly, I'm assuming those windows were > created with Qt. Agreed. Yes the unit tests will create and destroy windows quickly. >> 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. > I think we have a slight misunderstanding here. My Qt-Jambi DLLs also DO > NOT have the '1' digit in their name either. However if I start my > Qt-Jambi application it starts looking for the DLLs with '1' in their name. What does your META-INF/MANIFEST.MF contain (from the 2 main JARs) ? and your qtjambi-deployment.xml ? Ok and fine com/trolltech/qt/version.properties file from the Qt Jambi Java JAR, what is the contents ? Mine has an empty string but the variable is set. Is the "1" included in there ? Does MANIFEST.MF contain X-QtJambi-SoName-Version header ? (I think not as that patch was not until after a6d6e8da 2012-07-05 this is something not yet tested on windows, these patches only made it to master in the last week and I don't recommend you attempt anything with them yet, stick with version 03a66f3) Right the following test works for me (from the toplevel build directory Qt Jambi) : rem *** This is to fix a zlib1.dll DLL loading issue, rem *** my Qt and OpenSSL both use zlib from a DLL but rem *** your system might not. rem *** You need to fixup the dirnames check it really exists rem *** Maybe you can try without this change first and report rem *** the results. set PATH=build\platform-output\lib;%PATH% rem *** You need to fixup the filenames check they exists and rem *** fix to your version maybe 4.8.x java -cp qtjambi-4.7.4.jar;build\qtjambi-win32-msvc2010-4.7.4-beta-4.jar;qtjambi-designer-4.7.4.jar;qtjambi-examples-4.7.4.jar com.trolltech.launcher.Launcher From a fresh reboot and new cmd.exe console. Where java -version works and prints Java5 for me (as I build against it to check we did not use JRE6+ APIs) the above 2 commands work. This runs the demo launcher application on my windows build. Does the same work for you ? This is about a real world an example as I can think up. For me it works as I'd expect it to. You pick the demo code you want to try from the list on the left and them press the Launch button from the bottom right. > The contents of the JAR I build (qtjambi-win32-msvc2010-4.8.3.jar) > contains the following DLLs: > > * com_trolltech_qt_XYZ.dll, where XYZ is the name of the subsystem > (i.e. core, gui,...), and without the '1' suffix. > * qtjambi.dll > * the necessary DLLs from Qt itself. > > When I start my application with this JAR out-of-the-box, I do get these > messages: > > Loading library: 'qtjambi1.dll'... > > So, these DLLs don't exist. I get the impression wants to load the wrong > DLLs. It thinks the DSOs have a version 1 in their filename (like on Linux). The question is why does your build think that (when mine does not) ? >> 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. > The line is this with me: > [qtjambi-initialize-build] qtjambi.soname.version.major: <empty-string> > (set blank by init) Again this is good. Still pointing at some issue relating to that change that affects real applications but not unit tests. But the Launcher test is a contra-indicator, unless you tell me that also works for you. Then we need to look at your app and its deployment. Darryl _______________________________________________ Qt-jambi-interest mailing list Qt-jambi-interest@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-jambi-interest
