Build fails with 3 errors

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Build all lib dependencies (iconv, geos, geos_c, proj4) with MSVC 2008 / 
SDK7.0 x64
2. Add \bin, \lib, and \include dependency paths to setup.cfg (or directly to 
setup.py)
3. Run 'python setup.py build'

What is the expected output? What do you see instead?

Build should complete creation of all libs, dlls, etc. and be ready to perform 
install. Instead, build is failing with the following errors...

spatialite.c
amalgamation\spatialite.c(69910) : error C2075: 'spatialiteversion' : array 
initialization needs curly braces
amalgamation\spatialite.c(69910) : error C2143: syntax error : missing ';' 
before 'constant'
lex.VanuatuWkt.c(1637) : warning C4273: '_isatty' : inconsistent dll linkage
        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\io.h(201) : see previous definition of '_isatty'
error: command '"C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2

What version of the product are you using? On what operating system?

Win7 x64
MSVC 2008
SDK 7.0 x64
Python 2.7.3
iconv 1.9.2
proj4 4.8.0
geos 3.3.5
pyspatialite 3.0.1

Please provide any additional information below.

I've tried compiling all dependency libraries with mingw-w64 and MSVC 2008, as 
well as compiling pyspatialite using the default MSVC and mingw-w64 (created a 
special subclass that calls mingw-w64 rather than mingw32). All methods fail 
during compile with the same errors above.
Is it possible that VERSION is not in the format that spatialiteversion[] is 
expecting?

Original issue reported on code.google.com by rob.walshaw2 on 31 Jul 2012 at 3:06

[GoogleCodeExporter]

Update: by changing line 69910 in spatialite.c from:

    const char spatialiteversion[] = VERSION;

to:

const char spatialiteversion[] = "3.0.1";

The first warning went away. This change matches the format in 2.4.0, which 
changed as of version 3.0.0.

However, the second warning remains and now a third arises...

spatialite.c
lex.VanuatuWkt.c(1637) : warning C4273: '_isatty' : inconsistent dll linkage
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\io.h(201) : see 
previous definition of '_isatty'
lex.Gml.c(851) : warning C4102: 'find_rule' : unreferenced label
c:\temp\pyspatialite\amalgamation\spatialite.c(25707) : warning C4700: 
uninitialized local variable 'dummy' used

This change seems to allow the compile to move forward; however, I'm running 
into another problem that is blocking it from completing - nothing to do with 
pyspatialite, though. Once I clear up that problem, I'll report back here 
whether the compile completes succcessfully.

-RMWChaos

Original comment by rob.walshaw2 on 31 Jul 2012 at 1:17

[GoogleCodeExporter]

Once I worked around the mislabeled library, the build continued a bit further; 
the three warnings above remain, and now a fourth...

   Creating library build\temp.win-amd64-2.7\Release\src\_spatialite.lib and
 object build\temp.win-amd64-2.7\Release\src\_spatialite.exp
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs
; use /NODEFAULTLIB:library

At which point, the build seems to complete without any errors. I run 'python 
setup.py install', and it seems to complete successfully.

Going to run some tests, but assuming the warnings above are nothing to be 
overly concerned about, making the change to line 69910 in spatialite.c from 
VERSION to "3.0.1" seems to have gotten around the problem.

Is this simply a matter of a missing definition for VERSION?

Thanks,

-RMWChaos

Original comment by rob.walshaw2 on 31 Jul 2012 at 1:57

[GoogleCodeExporter]

Whoops! line 69910 in spatialite.c should read:

    const char spatialiteversion[] = "2.3.1";

To reflect the version of spatialite, not "3.0.1" (the version of 
pyspatialite). Tests fail otherwise. Passing so far with the correct version 
entered, however.

-RMWChaos

Original comment by rob.walshaw2 on 31 Jul 2012 at 3:15

[GoogleCodeExporter]

Restuls of tests...

C:\Python27\Lib\site-packages\pyspatialite\test>python dbapi.py
.......................................................................
....................
----------------------------------------------------------------------
Ran 96 tests in 0.203s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python dump.py
.
----------------------------------------------------------------------
Ran 1 test in 0.031s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python factory.py
.............
----------------------------------------------------------------------
Ran 13 tests in 0.078s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python hooks.py
.........
----------------------------------------------------------------------
Ran 9 tests in 0.031s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python regression.py
..................
----------------------------------------------------------------------
Ran 18 tests in 0.093s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python spatial.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.015s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python transactions.py
............
----------------------------------------------------------------------
Ran 12 tests in 0.656s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python types.py
.................................
----------------------------------------------------------------------
Ran 33 tests in 0.094s

OK

C:\Python27\Lib\site-packages\pyspatialite\test>python userfunctions.py
............................
----------------------------------------------------------------------
Ran 28 tests in 0.078s

OK

Original comment by rob.walshaw2 on 31 Jul 2012 at 3:17

[GoogleCodeExporter]

Should be my final comment with this issue...

I ran the spatialite_sample.py code from this link:

http://www.gaia-gis.it/spatialite-2.4.0-4/splite-python.html

And it successfully created a test_db.sqlite file and populated it with 
thousands of entries. Based on this, I'm going forward with the belief that 
everything compiled and installed properly (for now).

Further tests with my application that I intend to use spatialite for may find 
issues otherwise, but will likley be difficult to determine whether it's due to 
a problem during compile or with spatialite code / python APIs.

So unless something is very obviously caused by a problem with the warnings 
during compile, I likely won't be posting future errors here, but rather in the 
gaia-gis site.

Thanks,

-RMWChaos

Original comment by rob.walshaw2 on 31 Jul 2012 at 4:51

[GoogleCodeExporter]

Well, now I have to make a liar out of myself. I looked more closely at the 
spatial.py test code, and it's hard-coded to look for pyspatialite version 
2.3.1, which is why that particular test failed. So VERSION can (and should) 
equal 3.0.1, just modify spatial.py to compare against 3.0.1 instead and it 
passes.

Now having said that, I've looked more closely at why the build is failing 
without manually changing line 69910 in spatialite.c from the 3.0.1 
amalgamation. If I insert a line at the top of the file, say around line 54, 
that reads:

   #define VERSION "3.0.1"

The build will complain about a macro redefinition - no biggie - but it will 
successfully complete the build process. So the best that I can tell is that 
the macro definition in setup.py is not being passed properly.

I've looked more closely at setup.py, and to be honest, I'm a bit confused 
about how its structured. I'm not quite sure what the reasoning is behind the 
separate MyBuildExt class.

I've tried creating a setup.cfg with a [global] header and added a new macro 
definition for VERSION there, as well as including one directly in setup.py 
globals AND in MyBuildExt. In all cases, VERSION is not being passed properly 
when building spatialite.c.

The only way I've been able to work around this is to override VERSION directly 
in spatialite.c one way or the other.

I'll keep working at it, but that's all I've got for now. Hopefully, someone 
can figure out what I'm missing here.

Thanks,

-RMWChaos

Original comment by rob.walshaw2 on 2 Aug 2012 at 1:32