[Qgis-developer] Updating Win Build - stuck
S Mizuno
spookster at netzero.net
Fri Nov 13 19:13:16 EST 2009
Alex,
Here are some of my notes about compiling QGIS and GRASS using MinGW & msys. Most are
cryptic, since I haven't endeavored to make a unified document for others to use. They
may have outdated or flat out wrong information (as I learned more about compiling with
MinGW).
List of files with short description:
_compiling notes-20080629.txt outlines the strategy I used to set up my build system
compile_run-20081018.txt the steps I use to compile QGIS
compile_use_with_GRASS6.4.0-20090501.txt how I integrated GRASS 6.4.0 Windows binary with
QGIS
qgis-cmakefile-changes-20080803.txt how I modify some *.cmake files for less hassle with
cmake
vars-452.bat sample batch file that sets the compiling environment
I haven't included notes about each of the libraries I have compiled. If you have
questions about a library, let me know which one and I can send you the note. Some of the
libraries can't be built without modifying the source in some way. I have attempted to
find the root cause of these problems, rather than just find a work-around. (But there
are some I haven't figured out yet)
I currently use binaries available for Qt 4.5.x, Python 2.6.x and PostgreSQL 8.3.x. And I
try to keep Proj, GEOS and GDAL at current versions by compiling them as new versions are
released.
Presently, I have integrated the Windows GRASS 6.4.0RC build available from the OSGEO
site by adding the GRASS directories to PATH. I moved some of the .exe and .dll files
from various locations to reduce the number of directories listed in PATH. I believe this
works, but I have not tested it extensively as I don't use GRASS much. I can load GRASS
data layers and have tried a GRASS tool or two.
I had compiled GRASS 6.3.0 and was using that until I noticed the 6.4 binary was
available. I have looked into compiling 6.4 because I wanted it to use the versions of
libraries that I use for QGIS, but I haven't attempted building it yet.
Have you built GRASS 6.4.0?
The procedure I use to build QGIS has served me well for more than a year now. I have
only made minor adjustments as QGIS or some libraries have changed.
I normally build on a Windows XP system, but I have successfully compiled on a Windows
Vista 32-bit system and didn't have any problems beyond issues with User Access Control
(be sure to run as Administrator).
Please let me know where you are at in trying to compile QGIS and GRASS so I can be of
more assistance.
Steve
---------- Original Message ----------
From: Alex Mandel <tech_dev at wildintellect.com>
To: S Mizuno <spookster at netzero.net>
Cc: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Updating Win Build - stuck
Date: Tue, 10 Nov 2009 00:37:20 -0800
Steve,
I'd be very interested in seeing any other notes you have on the
process. If you are building via MinGW and are willing to share in the
process I will be happy to help get your builds into the NSIS script to
create a new version of the Standalone installer.
My only goal here is a standalone installer with grass and python like
Macro used to make. It would be great if this didn't rely on a single
person as in the past so I would be very happy to collaborate with you.
FYI, I have access to virtual machines of most versions of windows for
building and testing but do not use windows myself(anymore).
Thanks,
Alex
S Mizuno wrote:
> Alex,
>
> I believe the problem is that qgssvnversion.h is not being constructed properly due to a test for MSVC in CMakeLists.txt in the top level source directory that should also test for MINGW , like in Python.cmake as you found. *nix commands are attempted, but fail since it is a Windows system.
>
> see attached patch file
>
> I hope this helps.
>
> I have been using MinGW building for some time now and have some things I do to make compiling a little easier on my build system, which is somewhat different from the way Marco Pasetti documented Windows building. I would be willing to share these if you are interested. Most of these allow CMake to find libraries and headers without having to manually set the variables.
>
> Steve
>
> ---------- Original Message ----------
> From: Alex Mandel <tech_dev at wildintellect.com>
> To: qgis-developer <qgis-developer at lists.osgeo.org>
> Subject: [Qgis-developer] Updating Win Build - stuck
> Date: Sun, 08 Nov 2009 00:05:10 -0800
>
> All,
>
> I've been working on bringing the mingw/msys build back up to date with
> a working GRASS. So far via Marco's instructions and some shortcutting
> via OSGeo4w I think I'm getting close.
>
> Ran into an error somewhere between 3-7%, see
> http://img8.imageshack.us/img8/232/cmakeerror.png
>
> Based on ADKPete's suggestion I tried an mingw build of GEOS instead of
> osgeo4w but that didn't seem to change anything.
>
> Oh and an FYI, Python.cmake should be changed to check for MINGW or MSVC
> for when to decide to use pyuic4.bat and pyrcc4.bat, or alternately just
> use WIN32. I manually hacked it with that for now, not 100% what the
> final solution is to ensure both build types with find the right python
> files in the cmakesetup.
>
> Thanks,
> Alex
____________________________________________________________
One Up the Competition
Earn your MBA from Post University. Free textbooks for new students!
http://thirdpartyoffers.netzero.net/TGL2231/c?cp=spp0e4aeF70iAd0E4NyapAAAJz5YOwpkkhYzlrNtu8XFIBruAAQAAAAFAAAAAACkxz4AAAMlAAAAAAAAAAAAAAAAABIhWQAAAAA=
-------------- next part --------------
6/29/2008
notes on compiling with MinGW/MSys
MinGW 5.1.4 / gcc suite 3.4.5 (gcc, g++, ld, etc.) / binutils 2.17.50 / MinGW32-make 3.81 / w32api 3.11 / mingw-utils 0.3
MSys 1.0.10 / msysDTK 1.0.1
MinGW and MSys are installed to default locations - C:\MinGW, C:\msys\1.0 respectively
I create the following directories in C:\msys\1.0\local\ (/usr/local/ in MSys terminal)
bin\
include\
lib\
share\
to hold compiled sources' installation.
I have set out to prove that:
+ pre-built libraries/apps installed to their 'default' locations, such as C:\Program Files\... can be used for compiling
+ doing minimal tweaking of configure / makefiles to get Windows binaries is possible in most cases
+ it is not necessary to specify import libs explicitly when linking
+
1. the MinGW version of gcc suite prefers import libs to static libs by way of the file name - Import lib: *.dll.a - Static lib *.a
That is, *.dll.a is searched for first.
It is possible to name the import lib like the static lib and it will work.
An example where this is not true is zlib - the import lib is libzdll.a (should be libz.dll.a) which either needs to be coded into makefile/link commands that reference it, or to rename it. A good practice would be to modify the zlib makefile to output the 'standard' name, rather than to fix other makefiles.
2. some source packages are already set up to build Windows executables and just need minor adjustment of paths, perhaps.
Other packages may need extensive work in order to build Windows executables, sometimes even figuring out the compiler commands.
3. for compiling GRASS and QGIS, need to have Bison and Flex; get these from the GnuWin32 project and unzip to /usr/local/
bison-2.1-bin.zip
bison-2.1-dep.zip
flex-2.5.4a-1-bin.zip
This sort of contaminates my preferred install location, but I don't want them in the MSys main bin directory either.
Perhaps they should be installed in C:\MinGW\bin ? Or some other location? They are not MSys executables.
4. I am choosing to use official Windows binaries for PostgreSQL, Python - unless they don't work out.
Paths to these binaries' locations for compiling, if they contain spaces, should be via the shortname notation: C:\Program Files\... ---> C:\Progra~1\... or /c/Progra~1/...
These will be in their respective 'normal' locations. Will need to provide PATH settings somehow. I'm not keen on placing them in the system PATH (because certain files tend to be in multiple places), but that is probably the best overall strategy.
Otherwise, various files/directories will need to be copied to the QGIS installed location, for example. Need to build a list of files that are necessary for this method.
5. I wish to have a fairly complete set of libraries, not just for GRASS and QGIS
6. I wish to have various utility programs from the various libraries available for use, unlike QGIS, which sometimes has some of these and sometimes not.
Reason: have a single set of GIS apps/libs, rather than several different underlying versions of libraries
7. I generally build both static and dynamic (dll) libraries mainly to avoid fiddling with configuration switches and as long as the static libs aren't linked by default.
8a. some libs/utils/apps (Qt, sip, PyQt) may be compiled from a Windows command prompt; need to use mingw32-make for these
8b. if a source package has a makefile for MinGW this probably means using a Windows command prompt to build in, rather than a MSys terminal. Need to check the makefile to see if it has 'copy' vs. 'cp' commands, for example.
Some packages may have a MSys makefile.
9. although I have read that linking to a .dll directly is supposed to work, I have found trying this with libpq.dll doesn't work at run-time; it links ok, but causes QGIS to crash on getting PostGIS data. This is probably why some people claim that using the 'official' Windows binaries doesn't work.
Therefore, always be sure that the libs to link are *.a or *.dll.a (import libs)
order of compilation for GRASS, QGIS
these have no dependencies or dependents; may be compiled in any order before the main application
fftw
gsl
PDcurses
xdr
these have or are dependencies; must be compiled in this order (at least, anything that something else depends on must be done beforehand)
zlib [could use available binaries]
libpng (zlib)
jpeg
tiff (jpeg, zlib)
proj
libgeotiff (tiff, proj)
freetype (zlib)
curl
expat
PostgreSQL I'm not compiling this - using available binaries
Python I'm not compiling this - using available binaries
sqlite [could use available binaries]
geos (proj)
gdal (curl, expat, jpeg, libgeotiff, tiff, zlib, geos, proj, postgresql, sqlite)
tcl
tk (tcl)
sip
PyQt
main applications
GRASS
gdal (to include GRASS)
QGIS
Except for QGIS' use of Python via PyQt, I am building no bindings using SWIG or any other way.
================================================================
6/30/2008
After compiling all the above listed packages except for QGIS, I copied the entire MSys installation to a USB flash memory drive and tried running on the Compaq F712NR (Windows Vista). Also copied selected pieces of PostgreSQL 8.2.5 (libpq.dll and its dependencies) into a separate directory.
I have run GRASS to the extent of creating a GRASS GIS database, initializing it using EPSG code.
7/1/2008
have found (again) in QGIS building instructions, in the part about building the Msys environment, notes about changing configure's notion of command line length for Msys - replace 8192 with 32768 - this was in regard to GDAL building
Probably should do this for GEOS and GDAL building.
7/5/2008 - 7/12/2008
FYI - 1. probably should have path to Qt, Python, GRASS, PostgreSQL (and any others) executables, usually .../bin, added in Sys command window.
2. various libs and apps often have their own set of environment variables to help other apps and themselves find supporting files. Need to learn which ones to use.
list of vars.: PROJ_LIB, QTDIR
GISBASE, GISDBASE, GRASS_WISH and others for GRASS may be set -- they are normally set by grass63 startup file
These should be set appropriately for the command prompt in use.
For compiling and running GRASS, QGIS set the following in PATH
Windows:
C:\MinGW\bin
C:\msys\1.0\local\bin
C:\Program Files\PostgreSQL\8.2\bin
C:\Python25
C:\Qt\4.4.0\bin
C:\msys\1.0\local\grass-6.3.0\bin
C:\msys\1.0\local\grass-6.3.0\lib
C:\msys\1.0\local\tcl-tk\bin
C:\Internet\gpsbabel.org\gpsbabel-1.3.5
C:\Progam Files\qgis0.10.0 (to run QGIS; this is default location)
MSys:
/c/MinGW/bin (this should already be in PATH as /mingw/bin)
/usr/local/bin (this should already be in PATH -- MSys default)
/c/Progra~1/PostgreSQL/8.2/bin
/c/Python25
/c/Qt/4.4.0/bin
/usr/local/grass-6.3.0/bin
/usr/local/grass-6.3.0/lib
/usr/local/tcl-tk/bin
/c/Internet/gpsbabel.org/gpsbabel-1.3.5
/c/Proga~1/qgis0.10.0 (to run QGIS; this is default location)
The file mingwm10.dll from MinGW installation needs to available to Qt (and others?) if trying to make a combined directory for installation, like the QGIS Windows distro.
7/26/2008
for QGIS, should have SubVersion Number (svn) installed so the svn version detection will get the version and whether it is modified.
unpack svn-win32-1.4.4.zip to C:\Program Files\Subversion\1.4.4\
add the path to svn bin directory to PATH
7/28/2008
have found that Qt has a make.bat which might get confusing as to which make is used depending on order of directories in PATH.
It seems best to remove or rename make.bat and specifically call mingw32-make when needed.
This brings to mind a question - what does either of the make commands call if they shell make? Need to test this.
====================================================
3/14/2009
having trouble with tee.exe (/bin/tee.exe) - it seems to have been truncated to 0 bytes (probably a mistake in a command line; the date is 7/26/2008)
Need to find out which MSys archive file has it so I can replace it.
Fixed by copying tee.exe from another installation.
3/15/2009
have compiled new versions of:
proj 4.6.1
geos 3.0.3
sqlite 3.6.11
gdal 1.6.0
and they are now part my MSys/MinGW build environment
3/16/2009
compiled libpng 1.2.35 using my modifications and procedures -- ok (see notes for 1.2.32 & 1.2.29)
did not recompile GDAL or QGIS because of this as the API shouldn't have changed
3/18/2009
redirecting error output and std out to a file (at least in MSys -- haven't tried Windows command prompt)
...command... >OUTFILE.TXT >2&1
What is being done:
1. redirect std out to a file [ >OUTFILE.TXT ]
2. then redirect error out to std out [ 2>&1 ]
It doesn't work to redirect error out to std out, then std out to file.
I got the idea to try this from redir in the MinGW distribution (but I couldn't get redir to do what I wanted)
-------------- next part --------------
10/18/2008, 11/30/2008
compiling Quantum GIS on ZD8000 - short list of instructions
(in Windows command prompt)
enter the compiling directory:
cd \_compile
vars-440 (varies with Qt version)
create the directory for the QGIS SVN:
cd \_compile\QuantumGIS
md r9462 (varies with the SVN commit)
(retrieve the SVN using Compaq F712NR computer and archive it)
cd <the qgis svn dir base>
svn co http://... qgis (first time)
svn up (subsequent updates)
tar jcvf qgis-r9462.tar.bz2 qgis (varies with the SVN commit)
(transfer to ZD8000)
(unpack the .bz2 archive in the MSys environment)
cd /c/_compile/QuantumGIS/r9462 (varies with the SVN commit)
tar jxvf qgis-r9462.tar.bz2 (use MSys environment; varies with the SVN commit)
(back in Windows command prompt)
md \_compile\QuantumGIS\r9462\qgis\build (varies with the SVN commit)
cd \_compile\QuantumGIS\r9462\qgis\build (varies with the SVN commit)
(patch the source as necessary in MSys environment)
(prepare the make)
cmakesetup .. (change the install location to match the SVN commit; don't seem to need OpenSSL even though there are settings for include and libs - only Dxf2Shp Converter currently has openssl dll [ssleay32.dll] linked in)
(compile)
mingw32-make install
(run)
\progra~1\qgis-svn-9462\qgis (short name of "Program Files"; varies with the SVN commit)
-or-
"%ProgramFiles%\qgis-svn-9462\qgis" (need quotes because of spaces; varies with the SVN commit)
NOTES:
I have discovered that QGIS compiled without Python bindings will work with Python if the bindings are available (previous compiling) - I had thought the capability would be disabled.
==============================================
10/26/2008 have switched to CMake 2.6.2 - needed to modify FindPythonInterp.cmake to allow it to find Python 2.6 (was only partially set up)
Note that CMake 2.4 needs more extensive fix-ups for Python 2.6.
Have switched to Python 2.6
With Qt > 4.4.0 there appears to be a rendering problem to actual printers, where only the area contained by the bounding box of a POINT layer gets width settings used on lines/polygons; outside of this area is just one pixel width; also is not antialiased outside of the BB.
11/30/2008 with r9720 (or some earlier rev.) need svn higher than v. 1.4.4 I was using; upgraded to svn 1.5.4
when using CMake 2.6 OpenSSL package is one of the defaults (??) CMake looks for; there is nothing I can find in QGIS that specifies OpenSSL.
The odd thing is that the .dll found is linked only to the Dxf2Shp Converter plugin, not to every module.
Without taking the time to pick apart QGIS build instructions to CMake I don't see why OpenSSL is linked to the one module. A quick check of the CMakeList.txt for it doesn't reveal any use of OpenSSL.
-------------- next part --------------
compiling QGIS with GRASS 6.4.0 Windows binary from OSGEO/GRASS
5/1/2009
after changing c:\_compile\vars-451.bat to set PATH and BASE_DIRS to the new locations for GRASS (lib and bin), QGIS would compile
But GRASS was not available when running QGIS.
Found that other directories in the GRASS tree are needed: extralib, extrabin, sqlite/bin, tcl-tk/bin (not sure if all are needed - I assume so, except if the files in these are available in other locations)
However, libpq.dll, ssleay32.dll, libeay32.dll are not compatible with QGIS (missing password functions in libpq; then the proper libpq needs the proper SSL libs mentioned)
Renaming the 3 dlls above allowed QGIS to load GRASS plugin and it works, at least to some degree - not well tested.
In addition, there is now a Python problem - can't load SIP
Conclusion: need to combine some of the files in various directories to cut the number of paths needed; and need to remove the 3 dlls and hope that GRASS can use the libpq.dll from the PostgreSQL 8.3 binary I installed.
Also, need to decide what to do about SQLite, and some other libs - GDAL, GEOS - for example, as they are different versions, possibly different names.
-------------- next part --------------
20080803
Quantum GIS svn base=r8952
changes to various CMake configuration input files
cmake/Find?.cmake
In order to make configuring QGIS in Windows build environment (MSys) easier, I have modified several .cmake files
Most of the changes aren't needed if all libraries were in one of the so-called standard locations (implicit or explicitly listed), but this is not always so, especially in Windows.
The gist of the modifications:
+ allow use of environment variable BASE_DIRS where it is set to a list of directories to search to satisfy dependencies
example: BASE_DIRS=C:/msys/1.0/local;C:/Program Files/PostgreSQL/8.2;C:/msys/1.0/local/grass-6.3.0
These are where I typically put the various libraries - either compiled or from a binary distribution.
The reason I didn't use LIB_DIR is that it is used in particular ways as a single directory value in some of the cmake files and I didn't want to break that use.
It also doesn't reflect the notion that there may be a list of directories.
+ in the cmake/Find*.cmake files I have added:
ENV BASE_DIRS
PATH_SUFFIXES include -or- PATH_SUFFIXES lib
in the FIND_PATH(), FIND_LIBRARY() calls.
As a result of this change, the /include and /lib on the listed paths is not necessary, so I removed these.
+ cmake/FindPostgres.cmake
+ added missing "${POSTGRESQL_PREFIX}" in the FIND_PATH() and FIND_LIBRARY() calls. This is one cause of extra effort to configure.
+ added NO_DEFAULT_PATH to FIND_LIBRARY(), so the libpq.dll file is not found first (I have had trouble running QGIS when linked directly to the .dll, even though it is supposed to work)
+ added basic FIND_LIBRARY() call to then search default locations when all else fails.
+ in some of the *.cmake files I added the PATHS parameter keyword, which was missing from FIND_PATH() (it is required when using certain other keywords; it is also the formal way to write the call)
Some of the changes are inside an IF (WIN32) block, so they affect only Windows building. Some files don't have the distinction between WIN32 and UNIX, so the changes will affect all platforms.
Haven't tested on MSVC, Linux or Mac.
My recommended way to run CMakeSetup:
1. set BASE_DIRS as necessary
2. run CMake - configure
3. inspect the various ...INCLUDE and ...LIBRARY settings to see that they contain the desired values (particularly *.dll.a or *.a lib names)
4. if you find a need to change BASE_DIRS, clear the cache on next run of CMake
Because of the way CMake operates it may be necessary to clear the cache even when changing the settings for various ...PREFIX settings.
5. make other settings, such as output location, compiler flags, etc.
6. last configure
7. OK (generate)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vars-452.bat
Type: application/octet-stream
Size: 1235 bytes
Desc: vars-452.bat
Url : http://lists.osgeo.org/pipermail/qgis-developer/attachments/20091114/9f42b69c/vars-452.obj
More information about the Qgis-developer
mailing list