Bug report #7523
Windows build WITHOUT OSGeo4W
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Build/Install | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Windows 7 | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | end of life |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 16469 |
Description
Hi,
I hesitated a bit between a bug issue and a mail on the mailing list, but since there is a mix of bug report and other infos here it goes.
I finally managed to build QGis master on Windows7 but using only dependencies built by me with VS2010. The only exception to this was python and its dependencies, where I used WinPython portable 2.7.3
Give this setup, I didn't exactly follow the instructions in the INSTALL file. Namely I used had cmake generate a nmake makefile and put the dependencies list on a separate file and made it include in main CmakeList.txt and here started the issues. Example, although I declare the dependencies as
set(EXPAT_INCLUDE_DIR "C:/programs/compa_libs/expat-2.0.1/compileds/VC10_32/include")
set(EXPAT_LIBRARY "C:/programs/compa_libs/expat-2.0.1/compileds/VC10_32/lib/libexpat.lib")
I still het complains about missing headers (e.g.)
c:\\programs\\qgisgit\\quantum-gis\\src\\core\\qgsgml.h(18) : fatal error C1083: Cannot open include file: 'expat.h': No such file or directory
note that the above declarations work fine for the libs, but the headers path are ignored. This happened to several dependencies so I joined them all in one single line and did
set INCLUDE=%INCLUDE%;C:/programs/compa_libs/expat-2.0.1/compileds/VC10_32/include;.......
so that solved the headers issue but than came this error
C:\\programs\\QGisGIT\\Quantum-GIS\\src\\app\\gps\\qwtpolar-1.0\\qwt_polar_item.cpp(346) : error C2027: use of undefined type 'QwtScaleDiv'
c:\\programs\\qgisgit\\quantum-gis\\src\\app\\gps\\qwtpolar-1.0\\qwt_polar_item.h(23) : see declaration of 'QwtScaleDiv'
here I couldn't come out with anything clever and just commented the 3 offending lines starting a #346 of qwt_polar_item.cpp
After came this "driver not found" error
X:\\Python27\\sip -w -e -x ...
So CMake failed to find SIP in WinPython and turned it into a "X:\\Python27\\sip". The solution here was to grep to all cmake generated build files that had that string and replace it by the correct value (in my case C:\\programs\\WinPython2.7.3_32\\python-2.7.3\\Lib\\site-packages\\PyQt4\\sip)
Near the end I got this one
sip: Deprecation warning: C:/programs/QGisGIT/Quantum-GIS/python/gui/gui.sip:2: %Module version number should be specified using the 'version' argument
A google search reveled this mail about the same error that makes reference to revision
http://lists.osgeo.org/pipermail/qgis-user/2012-January/015063.html
"Try the following patch (see revision 893f305c512a2b5266fb79165c34ac6da11e0a56 ):"
but apparently that does not solve this issue. Strangely the workaround was to repeat the 'nmake' command a couple of times until the above was taken as just a warning and the compilation proceeded.
Next:
[ 93%] Built target qgis_contrastenhancementtest
NMAKE : fatal error U1077: '..\\..\\output\\bin\\crssync.EXE' : return code '0xc0000139'
sip: Unable to find file "QtCore/QtCoremod.sip"
It turns out that the culprit is the QtCore4.dll in C:\\programs\\WinPython2.7.3_32\\python-2.7.3\\Lib\\site-packages\\PyQt4 that is found first and raises a:
entry point ??4QString@QAEAAV0
$$QAV0@@Z not found in QtCore4.dll
odd, because the dll has the same revision name as my Qt 4.8.4 installation but doesn't have that symbol indeed. The solution was to move it temporarily out of the way.
At the very end when I thought everything was finally done running "qgis.exe" failed because of:
"entry point _Z11qUncompressPKhi not found in QtCore4.dll"
This one took me long to decipher. To make it short, I don't know how it can happen but the fact is that problem was that the build process managed to pick up one QtCore4.dll that was higher in the path order and that was compiled with MinGW (it was either the one in MikTEX or GPSbabel but which one doesn't matter). I have no idea how that is possible when building with VS. I know that we can link against a .dll on Windows if we use gcc from MinGW but with CL!!!!!
Having found the cause, the solution was again to move those directories with a QtCore4.dll out of the path and it finally works.
Joaquim
History
#1 Updated by Jürgen Fischer over 11 years ago
And your point is? Poluting the path with incompatible DLLs is always a problem (eg. installing Qt or any other dependencies like OpenSSL into the system32 directory).
#2 Updated by Joaquim Luis over 11 years ago
I am well aware of the path pollution problem and when I found that pythonxy does install dlls in system32 (or, to be more precise, in SysWOW64) I replaced it by Winpython that is a portable version. I took all precautions to minimize the path problems but even so I was caught into some traps and reported them here for case someone else tries to do a build of a non-osgeo4w based, which is not such a silly idea if one want to have the latest GDAL or aim to do a 64 bits build.
But my main point is that I found problems in the build that are not related to path pollution. Namely:
- cmake recipes fail to acknowledge the INCLUDES and to correctly detect SIP
- there are two building errors:
1) the qwt_polar_item.cpp(346) : error C2027: use of undefined type 'QwtScaleDiv'
2) the warning .../gui/gui.sip:2: %Module version number should be specified ... stops the building process
#3 Updated by Jürgen Fischer over 11 years ago
Joaquim Luis wrote:
But my main point is that I found problems in the build that are not related to path pollution. Namely:
- cmake recipes fail to acknowledge the INCLUDES and to correctly detect SIP
include issue already fixed in b1c0963d5c0533. No idea where the X: comes from for the SIP problem.
- there are two building errors:
1) the qwt_polar_item.cpp(346) : error C2027: use of undefined type 'QwtScaleDiv'
"Fixed" in 04119d880. Qwt 6.1 isn't (yet?) supported in QwtPolar. Try 6.0.
2) the warning .../gui/gui.sip:2: %Module version number should be specified ... stops the building process
That's harmless - but fixing it would break support for earlier sip versions.
#4 Updated by Joaquim Luis over 11 years ago
include issue already fixed in b1c0963d5c0533. No idea where the X: comes from for the SIP problem.
Thanks for pointing where the fixes should go, but I'm afraid it's not yet enough. Can you please add these two too?
${SPATIALITE_INCLUDE_DIR}
${SQLITE3_INCLUDE_DIR}
but even with them, I still get header errors
C:\\programs\\QGisGIT\\Quantum-GIS\\src\\providers\\wms\\..\\..\\core\\qgsgml.h(18) : fatal error C1083: Cannot open include file:
c:\\programs\\qgisgit\\quantum-gis\\src\\providers\\spatialite\\qgsspatialiteprovider.h(20) : fatal error C1083: Cannot open include file: 'sqlite3.h':
- there are two building errors:
1) the qwt_polar_item.cpp(346) : error C2027: use of undefined type 'QwtScaleDiv'"Fixed" in 04119d880. Qwt 6.1 isn't (yet?) supported in QwtPolar. Try 6.0.
I am using 6.0.3 and still get the 'QwtScaleDiv' error
2) the warning .../gui/gui.sip:2: %Module version number should be specified ... stops the building process
That's harmless - but fixing it would break support for earlier sip versions.
I see, but it's not so harmless. An error follows and the building stops
Could you please add these lines to the main CMakeList.txt around line 30? It helps a lot when setting variables that will be seen in (and than no need to set them) CMake-gui.
- Include configuration options (default options and options overridden by user).
if (EXISTS "${CMAKE_SOURCE_DIR}/cmake/ConfigUser.cmake")
include ("${CMAKE_SOURCE_DIR}/cmake/ConfigUser.cmake")
endif (EXISTS "${CMAKE_SOURCE_DIR}/cmake/ConfigUser.cmake")
#5 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#6 Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from Open to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/