Menu
▾
▴
#149 Build of Qt example/bindings fails on Win7/Cygwin due to dllimport
I have been attempting to build in a Win7/Cygwin environment, enabling just the Qt devices/drivers. The cmake output is generated successfully (barring the errors about missing compilers for D/Ada), but past that compilation fails with
/cygdrive/d/plplot/plplot-5.10.0/bindings/qt_gui/plqt.cpp:28:28: error: definition of 'int vectorize' is marked 'dllimport'
PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
The verbose make output for the offending command is
cd /cygdrive/d/plplot/build/src && /usr/bin/c++.exe -DHAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -Dplplotd_EXPORTS -I/cygdrive/d/plplot/plplot-5.10.0/include -I/cygdrive/d/plplot/plplot-5.10.0/lib/qsastime -I/cygdrive/d/plplot/build -I/cygdrive/d/plplot/build/include -I/usr/include/qt4 -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -DUSINGDLL -o CMakeFiles/plplotd.dir/__/bindings/qt_gui/plqt.cpp.o -c /cygdrive/d/plplot/plplot-5.10.0/bindings/qt_gui/plqt.cpp
The macro USINGDLL is defined, so the macros in pldll.h are defining PLDLL(IM/EX)PORT. These seem to work fine as they are for most of the build but fall down when they are used for PLDLLIMPEXP_QT_DATA.
Note that the above is from a shared library build. When building a static library, it successfully compiles plqt.cpp, but then fails later to build the Qt examples.
I cannot verify the problem either on Linux or on MinGW/MSYS/Wine, but neither of those is the same as Cygwin, and I must admit that include/pldll.h.in is a thicket of preprocessor directives so you may have found either an issue with those on Cygwin or else an issue with CMake itself on Cygwin. See below.
On Linux here is the equivalent detailed build command that is used:
One difference is I am using the lastest master branch git version. So that means the "d" suffix is dropped from all libraries and a few other changes such as we now use PLPLOT_HAVE_CONFIG_H rather than HAVE_CONFIG_H to reduce the chance of name clashes. Just to be sure none of these changes or the large number of other changes in the git version since the 5.10.0 release have an effect, could you also try the git version as well?
One issue I noticed in comparing your build line with mine is that CMake defines the macro plplot(d)_EXPORTS in your case while it defines plplotqt_EXPORTS in mine. That lack of qt in your case is troubling. Do you continue to get that anomoly for the git version and also if you pay close attention (see below) to which CMake version you are using?
My understanding is there are subtle but important differences between a native Windows build of CMake (which you can download directly from the Kitware site) and the Cygwin version. For the Cygwin platform you must use the Cygwin version, i.e., Cygwin install the latest version of CMake that is accessible via Cygwin packaging and make sure that is first on your PATH if your system might also have a native CMake version installed somewhere.
I used Cygwin 64 bits to try and reproduce this problem, but all went well. Two possible differences from Will's configuration:
- Will may be using a 32-bits version of Cygwin and the problem is caused by the
idiosyncracies of Windows 32-bits.
- The problem occurs if you use the Windows interfacing of Qt (in my set-up that piece
of Qt is currently missing, as witnessed by the message from CMake:
-- Looking for Q_WS_WIN - not found)
My next step is to try and find that missing piece and try again.
Hm, it is worse. Some code diving revealed that Q_WS_WIN (the symbol that controls this) is not set for a Windows 64 bits platform:
if defined(Q_WS_WIN16) || defined(Q_WS_WIN32) || defined(Q_WS_WINCE)
define Q_WS_WIN
endif
So it is not a separate library I need :(. I will have to use Cygwin 32 bits instead
I can reproduce this error with a Cygwin 32 bits installation.
The culprit seems to be plplot_EXPORTS. I added this macro to the C++ compile command, but oddly the same error occurred. More investigation is required.
Arjen, the relevant macro name is plplotqt_EXPORTS so my bet is if you actually #define that macro (as opposed to plplot_EXPORTS) all will be well.
If that bet is correct, why should cmake on 32-bit Cygwin be defining the wrong macro name? (Note I asked this same rhetorical question above to the original bug reporter who was kind enough to give such detailed results you can see the misspelling of the macro, but you are in a much better position to understand how serious this CMake error is.) Does your 64-bit Cygwin platform misspell the macro name as well?
Arjen:
I have just checked our entire build tree for any mention of plplot_EXPORTS
or plplotqt_EXPORTS. The results are
So it appears that it is completely the cmake application's responsibility to set those macros as appropriate (plplot_EXPORTS when the plplot target is being built and plplotqt_EXPORTS when the plplotqt target is being built). And that is confirmed by the CMake documentation (look for target_EXPORTS in that documentation). So it is a serious error if cmake is getting that wrong on 32-bit Cygwin, but on no other platform (such as Linux for me and Cygwin-64-bit for you).
One possibility to explain any bizarre cmake result like this is if a wrong cmake version is being used that is incompatible with the platform. So to rule out that possibility, please check with
(which is more reliable than
) to make sure you are using the correct CMake version (i.e., the one that is part of your 32-bit Cygwin install and not the one that is part of your 64-bit Cygwin install or some native Windows version of CMake you have kicking around somewhere on your disk).
Last edit: Alan W. Irwin 2014-09-17
I checked the changes I made to the CMakeLists.txt file:
set_source_files_properties(
${qt_SOURCE}
PROPERTIES COMPILE_FLAGS "-DUSINGDLL -Dplplotqt_EXPORTS"
)
So at the very least it is the right macro. In the flags.make file that was generated from this I see:
CXX_DEFINES = -DPLPLOT_HAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -Dplplotqt_EXPORTS
Now, with the help of the gcc/g++ trick you proposed I should be able to find out why, nonetheless, the result is not as expected.
Using make VERBOSE=1, I got the following lines related to the file plqt.cpp:
/usr/bin/cmake.exe -E cmake_progress_report /cygdrive/d/plplot-svn/build-cygwin-qt/CMakeFiles 38
[ 28%] Building CXX object src/CMakeFiles/plplot.dir//bindings/qt_gui/plqt.cpp.o
cd /cygdrive/d/plplot-svn/build-cygwin-qt/src && /usr/bin/c++.exe -Dplplot_EXPORTS -DPLPLOT_HAVE_CONFIG_H -DQT_SVG_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -I/cygdrive/d/plplot-svn/plplot-plplot/include -I/cygdrive/d/plplot-svn/plplot-plplot/lib/qsastime -I/cygdrive/d/plplot-svn/build-cygwin-qt -I/cygdrive/d/plplot-svn/build-cygwin-qt/include -I/usr/include/qt4 -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -DUSINGDLL -o CMakeFiles/plplot.dir//bindings/qt_gui/plqt.cpp.o -c /cygdrive/d/plplot-svn/plplot-plplot/bindings/qt_gui/plqt.cpp
/cygdrive/d/plplot-svn/plplot-plplot/bindings/qt_gui/plqt.cpp:28:28: error: definition of ‘int vectorize’ is marked ‘dllimport’
PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
...
As you can see, there is a definition of plplot_EXPORTS but not of plplotqt_EXPORTS.
However, looking in the file build.make in bindings/qt_gui/CMakeFiles/plplotqt.dir, I see these lines:
bindings/qt_gui/CMakeFiles/plplotqt.dir/plqt.cpp.o: bindings/qt_gui/CMakeFiles/plplotqt.dir/flags.make
bindings/qt_gui/CMakeFiles/plplotqt.dir/plqt.cpp.o: /cygdrive/d/plplot-svn/plplot-plplot/bindings/qt_gui/plqt.cpp
$(CMAKE_COMMAND) -E cmake_progress_report /cygdrive/d/plplot-svn/build-cygwin-qt/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Building CXX object bindings/qt_gui/CMakeFiles/plplotqt.dir/plqt.cpp.o"
cd /cygdrive/d/plplot-svn/build-cygwin-qt/bindings/qt_gui && /usr/bin/c++.exe $(CXX_DEFINES) $(CXX_FLAGS) -DUSINGDLL -Dplplotqt_EXPORTS -o CMakeFiles/plplotqt.dir/plqt.cpp.o -c /cygdrive/d/plplot-svn/plplot-plplot/bindings/qt_gui/plqt.cpp
In other words: there is a discrepancy between what is actually used and what is apparently generated by CMake.
To solve this riddle, I scanned all files in the build directory for the string "plqt" and found that the Makefile in the src directory also contains a reference to plqt.cpp.
To conclude: this source file is referred to in two entirely different locations in the build procedure and the first location that is visited is the one under src. Hence to get the plplotqt_EXPORTS macro into the compile step it has to be added there.
Hm, adding the set_source_properties command to qt.cmake (where the dependency originates, as far as I can tell) does not work. So I added the definition directly in the source file. This made it compile correctly, but now there is a problem in building the cygplplot-12.dll:
Linking CXX shared library ../dll/cygplplot-12.dll
cd /cygdrive/d/plplot-svn/build-cygwin-qt/src && /usr/bin/cmake.exe -E cmake_link_script CMakeFiles/plplot.dir/link.txt --verbose=1
/usr/bin/c++.exe -shared -Wl,--enable-auto-import -o ../dll/cygplplot-12.dll -Wl,--out-implib,../dll/libplplot.dll.a -Wl,--major-image-version,12,--minor-image-version,0 CMakeFiles/plplot.dir/pdfutils.c.o CMakeFiles/plplot.dir/plaffine.c.o CMakeFiles/plplot.dir/plarc.c.o CMakeFiles/plplot.dir/plargs.c.o CMakeFiles/plplot.dir/plbox.c.o CMakeFiles/plplot.dir/plcont.c.o CMakeFiles/plplot.dir/plcore.c.o CMakeFiles/plplot.dir/plctrl.c.o CMakeFiles/plplot.dir/plcvt.c.o CMakeFiles/plplot.dir/pldtik.c.o CMakeFiles/plplot.dir/plf2ops.c.o CMakeFiles/plplot.dir/plfill.c.o CMakeFiles/plplot.dir/plfreetype.c.o CMakeFiles/plplot.dir/plgradient.c.o CMakeFiles/plplot.dir/plhist.c.o CMakeFiles/plplot.dir/plimage.c.o CMakeFiles/plplot.dir/plline.c.o CMakeFiles/plplot.dir/plmap.c.o CMakeFiles/plplot.dir/plot3d.c.o CMakeFiles/plplot.dir/plpage.c.o CMakeFiles/plplot.dir/plsdef.c.o CMakeFiles/plplot.dir/plshade.c.o CMakeFiles/plplot.dir/plstdio.c.o CMakeFiles/plplot.dir/plstripc.c.o CMakeFiles/plplot.dir/plsym.c.o CMakeFiles/plplot.dir/pltick.c.o CMakeFiles/plplot.dir/plvpor.c.o CMakeFiles/plplot.dir/plwind.c.o CMakeFiles/plplot.dir/plbuf.c.o CMakeFiles/plplot.dir/plgridd.c.o CMakeFiles/plplot.dir/plvect.c.o CMakeFiles/plplot.dir/mt19937ar.c.o CMakeFiles/plplot.dir/pltime.c.o CMakeFiles/plplot.dir/pllegend.c.o CMakeFiles/plplot.dir//drivers/qt.cpp.o CMakeFiles/plplot.dir//bindings/qt_gui/plqt.cpp.o CMakeFiles/plplot.dir//drivers/mem.c.o CMakeFiles/plplot.dir//drivers/null.c.o CMakeFiles/plplot.dir//drivers/ps.c.o CMakeFiles/plplot.dir//drivers/svg.c.o CMakeFiles/plplot.dir//drivers/wingcc.c.o CMakeFiles/plplot.dir//drivers/xfig.c.o CMakeFiles/plplot.dir//drivers/xwin.c.o -lSM -lICE -lX11 -lXext /usr/lib/w32api/libgdi32.a /usr/lib/w32api/libcomdlg32.a -lfreetype -lQtSvg -lQtGui -lQtCore -lfreetype ../dll/libcsirocsa.dll.a ../dll/libqsastime.dll.a -lQtSvg -lQtGui -lQtCore
CMakeFiles/plplot.dir//drivers/qt.cpp.o:qt.cpp:(.text+0xf): undefined reference to
_imp___ZN10QtPLDriver5mutexE' CMakeFiles/plplot.dir/__/drivers/qt.cpp.o:qt.cpp:(.text+0x161): undefined reference to_impZN10QtPLDriver5mutexE'CMakeFiles/plplot.dir/_/drivers/qt.cpp.o:qt.cpp:(.text+0x293): undefined reference to
_imp__vectorize' CMakeFiles/plplot.dir/__/drivers/qt.cpp.o:qt.cpp:(.text+0x29e): undefined reference to_implines_aa'...
This is nasty and requires further study.
You are evidentally testing the shared libraries/static devices case since device-driver code is being linked in for your test link above. The original bug reporter was not specific, but I am pretty sure he was reporting an issuefor the default shared libraries/dynamic devices case. Or is that case a problem even on 64-bit Cygwin?
Nevertheless you have found a linking bug for libplplot on 32-bit Cygwin for -DENABLE_DYNDRIVERS=OFF -DBUILD_SHARED_LIBS=ON so I just now looked at that exact case for Linux.
The link command used was the following:
I see in that command that just as in your case the link is with the -lQtSvg -lQtGui -lQtCore libraries. Furthermore, playing with nm (which should be available to you on Cygwin as well) shows the following results for some of your missing symbols:
These results very clearly indicate that on Linux the PLplot build itself (which is what is meant by the --defined-only option) and not the system Qt libraries defines QtPLDriver::mutex and vectorize. However, somehow those symbols (which are declared in qt.h and which are used in several different functions in drivers/qt.cpp) are not available when you build libplplot on your platform. What do similar nm commands show on your system?
The issue here might very well be how your system is compiling, e.g.,
which is declared in include/qt.h. What does the macro debugging trick I told you about say about the value of that PLDLLIMPEXP_QT_DATA( int ) macro?
Your extremely important remark made earlier which was
"To conclude: this source file is referred to in two entirely different locations in the build procedure and the first location that is visited is the one under src. Hence to get the plplotqt_EXPORTS macro into the compile step it has to be added there."
proved to be a key. That reminded me that for this special case (shared library/static device) a copy of bindings/qt-qut/plqt.cpp is compiled into libplplot. And nm --defined-only on Linux showed that vectorize, etc., were not being properly exported. (I didn't notice that build-system error before because it doesn't seem to have consequences on Linux for the various comprehensive tests we run on that platform.)
With commit 6f5dc7b I have now solved the Linux export problem, and my guess is it will also solve this entire bug on Cygwin. But please try your tests again (without any of the local workarounds you have applied for your previous tests) to test whether that is the case.
I will have a go with these changes (excluding my attempts at solving this ;)).
Yes, I can confirm this now: the build process is going smoothly with this change.
OK. Thanks for that test. I am changing status to closed-fixed.