Hi Alan,
When I tried my main application I got it to link OK but it would not run,
either it did nothing or just "terminates unexpectedly". I would guess it's
due to incompatible library calls between the two compiler versions. So I
decided this was a dead end and I had to have both Plplot and Qt built with
the sample compiler versions.
In the interest of simplicity I decided to go back to Qt 4.5.3 (Qt SDK
2009.04) which builds PLplot OK with the included compiler gcc 3.4.5. I did
that and built the Qt/Plplot program which had been OK with Qt 4.7.3 and it
ran and displayed graphs OK.
But I still have the same problem with my main application, it compiles and
links without problems but just crashes as soon as its invoked.
This is the link command cut and pasted direct from the Netbeans window,
most of it is supplied automatically by Netbeans but I had to specifically
tell Netbeans where to find the Plplot libraries.
g++ -enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o
dist/Debug/MinGW-Windows/QtProfile.exe object_script.QtProfile
-L'c:/Qt/2009.04/qt/lib' -lmingw32 -lqtmaind
build/Debug/MinGW-Windows/QtProfile_resource_res.o
C:/plplot-5.9.7/build/install/lib/libcsirocsa.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotcxxd.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotd.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotqtd.dll.a
C:/plplot-5.9.7/build/install/lib/libqsastime.dll.a -lQtGuid4 -lQtCored4
I thought it might be a problem with Netbeans/Qt rather than Plplot so I
thought I would try using QtCreator instead. I built and ran my simple
Plplot example that worked with the Netbeans link but it crashes
immediately.
QtCreator gives a bit more information:
Starting D:\Data\QtProjects\App\debug\App.exe...
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
D:\Data\QtProjects\App\debug\App.exe exited with code 3
This was the link command cut & pasted from the QtCreator window:
g++ -enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o
debug\App.exe debug/mainwindow.o debug/main.o debug/csvparser.o
debug/moc_mainwindow.o -L"c:\Qt\2009.04\qt\lib" -lmingw32 -lqtmaind
C:\plplot-5.9.7\build\install\lib\libplplotqtd.dll.a
C:\plplot-5.9.7\build\install\lib\libcsirocsa.dll.a
C:\plplot-5.9.7\build\install\lib\libplplotcxxd.dll.a
C:\plplot-5.9.7\build\install\lib\libplplotd.dll.a
C:\plplot-5.9.7\build\install\lib\libqsastime.dll.a -lQtGuid4 -lQtCored4
For this same program, the Netbeans link command that worked OK was:
g++ -enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -Wl,-s -mthreads -Wl -Wl,-subsystem,windows
-o dist/Release/MinGW-Windows/app.exe build/Release/MinGW-Windows/main.o
build/Release/MinGW-Windows/csvparser.o
build/Release/MinGW-Windows/mainwindow.o
build/Release/MinGW-Windows/moc_mainwindow.o -L'c:/Qt/2009.04/qt/lib'
-lmingw32 -lqtmain build/Release/MinGW-Windows/app_resource_res.o
C:/plplot-5.9.7/build/install/lib/libcsirocsa.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotcxxd.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotd.dll.a
C:/plplot-5.9.7/build/install/lib/libplplotqtd.dll.a
C:/plplot-5.9.7/build/install/lib/libqsastime.dll.a -lQtGui4 -lQtCore4
The difference is the -s option which removes all symbol table and
relocation information from the executable. In Netbeans I then built the
Debug version and it crashes just like the QtCreator version. Looking back
at my main application, I was building the debug version there too, so I
changed to build a release version and it all runs! I have a feeling it
would also run with Qt 4.7.3 linked with Plplot compiled with gcc 4.4.4. One
question, does the Plplot build include debug symbols and if so, can I
disable it somehow?
One problem I didn't mention earlier, when I built PLplot with gcc 3.4.5 it
would not build the C++ examples - it was missing the usleep() function, so
I think it's pretty pointless trying to run the test suite with this
compiler.
I still have another major module of my application to port across which
includes threads and USB access, and it is using usleep() so I am planning
to go back to Qt 4.7.3 and gcc 4.4.0 and try building Plplot with
TEST_DYNDRIVERS=OFF next
And just to clear up how I am choosing which compiler versions to run - for
the Plplot Cmake and make it's just a matter of having the correct compiler
and Qt binary directories in the PATH variable. For Netbeans you can
explicitly select a toolchain via a configuration window. So after I built
plplot with gcc 4.4.4 I just changed the PATH variable and Netbeans to point
at gcc 4.4.0 and it compiled and linked OK with the precompiled plplot
libraries.
Regards
Richard
-----Original Message-----
From: Alan W. Irwin [mailto:***@beluga.phys.uvic.ca]
Sent: 14 June 2011 18:03
To: Richard Jackson
Cc: 'Arjen Markus'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development
list'
Subject: RE: [Plplot-devel] Installing Plplot with Qt under Windows
[...]Looked at the difference between the plplot & qt link options,
see attached, but there is nothing I can make sense of - the PLplot
explicitly included many more windows standard dlls, but adding them
to qt makes no difference.
One thing that may be relevant though is that Netbeans & QtCreator
both include qtmain in the link, plplot example does not.
I assume you are comparing compile and link flags with different tool
chains. I would be interested in a comparison using the same Qt SDK tool
chain. You should be able to obtain the compile and link flags for
qt_example for that tool chain using the method below.
[...]Found this thread
http://www.qtforum.org/article/29890/qt-4-6-linking-problem.html
So that explains why Qt applications will not build with gcc versions
other that 4.4.0
I don't understand all the reasons given in that thread, but in any case I
don't think you should trust anything linking to the Qt libraries that is
not built with the identical tool chain (i.e. the MinGW one supplied by the
Qt SDK since it appears building Qt with a different tool chain is a tricky
business).
But what I still cannot understand is why the Plplot Qt driver will
not work with this same compiler and the Qt libraries linked with this
compiler.
Conversely, why does the Plplot build work with a later compiler such
as 4.4.4, and the Plplot qt_example work with it when a Netbeans or
QtCreator application does not?
It must be a compile or link flag issue. I would strip all tool-chain
related packages out of your test environment other than the MinGW-4.4.0
tool chain that comes with the Qt SDK to eliminate the possibility that you
are accessing an inconsistent version by mistake. Then make sure you can
compile, link, and run a simple Qt example without PLplot (as your tests
have indicated is possible before). Record all the compile flags and link
flags used for that build. Then look at the compile flags and link flags
for the cmake-configured "make VERBOSE=1 -k"
command to build qt_example with the same tool chain. (The -k option to
make should allow you to build as much as possible despite errors such as
occurs for the simple test done by the simple test-drv-info test.
Just now I looked at our cmake build-system logic, and it turns out you can
ignore the simple test-drv-info test completely by using the cmake option
-DTEST_DYNDRIVERS=OFF. (Sorry I did not remember this
before.) So I suggest you try that experiment just in case there is some
linking issue that is exclusive to that simple test that is not present for
qt_example. (You may still need to use the -k option in case there are
other build issues you want to bypass in order to build
qt_example.) Also, to build qt_example (and its necessary
dependencies) and run it just use the qt_example make target (i.e., use
"make VERBOSE=1 -k qt_example" to build that application, and the
test_qt_example target (i.e., use "make VERBOSE=1 -k test_qt_example") to
run it. Note, these targets will not be available unless you use the
-DBUILD_TEST=ON cmake option.
Anyhow, if you can get a cmake-built qt_example to build and run with the Qt
SDK version of the tool chain, then that potentially narrows down the
linking issue to just the test-drv-info case which would be a big step
forward.
I double checked the qt_example.cpp code, it's a straightforward qt
application just like I am trying to build with NetBeans or QtCreator.
I even copied it into Netbeans and QtCreator and then stripped out all
the Plplot references leaving just an empty application and I cannot
build it with either of them with gcc 4.4.4.
It sounds like both the Netbeans and QtCreator build environments will not
work on anything unless you are using the Qt SDK version of the tool chain.
That's a good constraint in my book since I don't trust any result with Qt
that is built with anything other than the Qt SDK version of the tool chain.
[...] Thinking some more about it, now that I have built Plplot
libraries with gcc 4.4.4, would it be possible to link those with a Qt
application built with gcc 4.4.0? Tried it and it works! - I can build
a fully featured Qt Plplot program with 3D graphs, menus, panels,
spinboxes etc.
That's a really strange result. Which tool chain are you using at run time?
I presume your PATH points to one of them but not both. (And if both it
will just use the first one in the PATH unless there is something missing
from that first tool chain that is resolved by the second one in your PATH.)
Anyhow, I don't trust this result, and it would be better to figure out why
cmake is not generating the correct compile flags/ linking flags for the Qt
SDK version of the tool chain.
I hope the -DTEST_DYNDRIVERS=OFF cmake option (see above) will help you to
figure that out.
Alan, I do intend to try the full MSYS build of the examples for you,
but right now my priority is to get my main application working
Understood. Such linking issues can usually be solved by something really
simple, but the complicated and time-consuming part is figuring it out!
Thanks for all your experiments trying to track down what the issue really
is.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________