Hi Richard:
On 2011-05-26 18:48+0100 Richard Jackson wrote:
> Alan,
>
> Thanks for the quick response.
>
> If I run ..\dll\test-drv-info.exe qt >
> C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc
> It produces the same qt.rc file but still I get the error:
>
> This application has requested the Runtime to terminate it in an unusual>
> way.
> Please contact the application's support team for more information.
>
> I am sure that test-drv-info is trying to return normally, I put a printf
> just before the return 0 statement to prove it.
Hmmm. I guess that means "return 0;" doesn't really mean exactly that
in all cases for the Windows platform. I strongly suspect (because
virtually all test-drv-info.exe issues concern linking) there is some
preceding run-time linking error that is causing the above error
message once the test-drv-info.exe application exits.
Under wine, I am more experienced with MinGW/MSYS (-G "MSYS Makefiles"
cmake option) rather than MinGW without MSYS (-G "MinGW Makefiles"
cmake option). In any case, note that MSYS has the really useful
ldd.exe application which allows you to analyze whether there are any
linking errors. It has been a while since I tried ldd.exe under wine,
but the equivalent ldd application under Linux gives the following
results for qt.so in the build tree
ldd -r drivers/qt.so
linux-vdso.so.1 => (0x00007fffea3ff000)
libplplotd.so.10 =>
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.10
(0x00007eff60598000)
libplplotqtd.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/bindings/qt_gui/libplplotqtd.so.0
(0x00007eff60376000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007eff6014c000)
libdl.so.2 => /lib/libdl.so.2 (0x00007eff5ff48000)
libcsirocsa.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0
(0x00007eff5fd3e000)
libcsironn.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0
(0x00007eff5fb34000)
libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5
(0x00007eff5f8d1000)
libqsastime.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0
(0x00007eff5f6c9000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007eff5f441000)
libm.so.6 => /lib/libm.so.6 (0x00007eff5f1bf000)
libQtSvg.so.4 => /usr/lib/libQtSvg.so.4 (0x00007eff5ef63000)
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007eff5e284000)
libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x00007eff5e03c000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007eff5dbaa000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007eff5d896000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007eff5d680000)
libc.so.6 => /lib/libc.so.6 (0x00007eff5d31e000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff60a21000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007eff5d107000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007eff5ced1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007eff5ccb5000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0x00007eff5ca9c000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007eff5c7bf000)
libpng12.so.0 => /lib/libpng12.so.0 (0x00007eff5c599000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007eff5c352000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007eff5c149000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007eff5bf2e000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007eff5bd24000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007eff5bb11000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007eff5b7d6000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007eff5b5d2000)
librt.so.1 => /lib/librt.so.1 (0x00007eff5b3c9000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007eff5b1a1000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x00007eff5af3c000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007eff5ad39000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007eff5ab09000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007eff5a904000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007eff5a6e8000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007eff5a4e2000)
You will note that all the PLplot build-tree and Qt libraries are
found in the correct location. In addition, the -r option for ldd
lets you know if there are any undefined symbols detected by the
run-time linking. (You often get such undefined symbols if there is a library
version mismatch or incompatibility). For my present Linux case,
there are no such undefined symbols, and that was also true for the wine
platform tests I did for the old MinGW installation but not true of
the later MinGW installation where ldd.exe -r showed missing symbols
indicating library version mismatches which explained the other
qt device errors I was getting from that MinGW version.
There may be some Windows application that does the same thing as ldd
which states which versions of libraries are being used to make sure
you are not using some stale older version by mistake due to an
incorrect PATH and which also checks for undefined symbols. Anyhow, I
would advise running ldd.exe or Windows equivalent to check for such
linking issues. Of course, the PATH (which, of course, has to include
the dll subdirectory of the build tree) which you use during your ldd
or equivalent test has to be the same as during your run of
test-drv-info.exe.
>
> So, I too was wondering if it was something to do with MinGW, but what I
> can't understand is why the preceding test-drv-info.exe qt xfig works OK.
That only tests the xfig device driver which has a much less complicated
run-time linking environment, i.e.,
ldd -r drivers/xfig.so
linux-vdso.so.1 => (0x00007fffe71d4000)
libplplotd.so.10 =>
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.10
(0x00007ff8a5cbb000)
libm.so.6 => /lib/libm.so.6 (0x00007ff8a5a17000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007ff8a580e000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ff8a560a000)
libcsirocsa.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0
(0x00007ff8a5400000)
libcsironn.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0
(0x00007ff8a51f6000)
libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5
(0x00007ff8a4f93000)
libqsastime.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0
(0x00007ff8a4d8b000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007ff8a4b03000)
libc.so.6 => /lib/libc.so.6 (0x00007ff8a47a2000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff8a613c000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007ff8a458a000)
>
> I only have the version of MinGW that comes with QtSDK - I decided on this
> because I also use Netbeans and they suggest this is the most stable. I may
> try another version.
I recommend the very latest automatic downloader/installer for
MinGW/MSYS. It is still rough around the edges, but it gets the
principal job done (at least under wine) which is to analyze the
zillions of different MinGW/MSYS dependencies and download and install
only the subset of MinGW/MSYS packages that you need.
>
> I looked at the Makefiles and the CMakefiles to see if I could persuade the
> Make to continue despite this error and see if it produces a working
> installation. But my knowledge of CMake is not good enough to find the
> right place to make this change.
>
> Maybe someone could help me on this?
The problem with the idea of skipping the test-drv-info.exe test is
that test is a really simple test of the qt device driver. If that
simple test cannot finish without run-time errors (almost always due
to bad run-time linking), then the same will likely be true if you run
one of the qt devices in a less superficial way. Thus, I am virtually
positive you must figure out the reason for the run-time error that
you are getting (e.g., by running ldd.exe or Windows equivalent) with
the simple test of qt.so. If you cannot figure out the reason for the
run-time error, I think you are stuck for the qt devices, and to
continue with PLplot you must disable the qt device driver and use
some different set of PLplot device (such as the cairo ones).
BTW, the qt and cairo devices are our best devices (with cairo
currently slightly in the lead). So if you lose qt but can get cairo
to work (or vice versa) the results generally look really good.
However, if you cannot get either to work, then there are plenty of
other devices that might meet your needs, but the fonts, for example,
may not look as good as for the qt and cairo devices.
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
__________________________
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
