Issues while compiling LibSpatiaLite 3.0.0 using Visual Studio (nmake)

[Dusan Paulovic]

Hi, I have just successfully build a non-amalgamated version of
SpatiaLite. We need SQLite3 library to be shared.
My goal is to inform contributors about some issues I have been
facing.

1. in DEF file is export 'gaiaBuildRing' which is not defined
r: to resolve it, just remove this one from list of exports (not
presented in amalgamation)

2. in 'src\spatialite\virtualfdo.c' is missing '_WIN32' definition for
'strncasecmp'
r: to resolve it add '#define strncasecmp _strnicmp' into '#ifdef
_WIN32' section

3. 'makefile.vc' does not correspond to DEF file, so on compile time
there are many
unreferenced exports mainly related to imports such as geoJSON,
KML, GML, etc.
r: to resolve it, in 'makefile.vc' add to 'LIBOBJ' variable
missing .obj files, or
remove related exports from DEF file.

4. OSGeo4W is no longer valid source of updated dependencies.
r: all needs to be taken from original pages and compiled manually

5. new versions of LibIConv and LibCharSet does not provide makefile
for VisualStudio
r: resolution is not needed, just link with libraries built in MinGW,
it should be
safe while those are depending only on MSVCRT.DLL


Dusan

[Brad Hards]

On Saturday 24 September 2011 01:30:51 Dusan Paulovic wrote:
> Hi, I have just successfully build a non-amalgamated version of
> SpatiaLite. We need SQLite3 library to be shared.
> My goal is to inform contributors about some issues I have been
> facing.
>
> 1. in DEF file is export 'gaiaBuildRing' which is not defined
> r: to resolve it, just remove this one from list of exports (not
> presented in amalgamation)

Looks reasonable. Can you please provide a patch?

> 2. in 'src\spatialite\virtualfdo.c' is missing '_WIN32' definition for
> 'strncasecmp'
> r: to resolve it add '#define strncasecmp _strnicmp' into '#ifdef
> _WIN32' section

Looks reasonable. Can you provide a patch?

> 3. 'makefile.vc' does not correspond to DEF file, so on compile time
> there are many
> unreferenced exports mainly related to imports such as geoJSON,
> KML, GML, etc.
> r: to resolve it, in 'makefile.vc' add to 'LIBOBJ' variable
> missing .obj files, or
> remove related exports from DEF file.

How big a change is this? If not too big, can you please provide a patch?
Otherwise, we may be able to rework this if / when we start to provide cmake
support.

> 4. OSGeo4W is no longer valid source of updated dependencies.
> r: all needs to be taken from original pages and compiled manually

Ouch. Can you provide a patch with some documentation changes to indicate
which which sources you used?

> 5. new versions of LibIConv and LibCharSet does not provide makefile
> for VisualStudio
> r: resolution is not needed, just link with libraries built in MinGW,
> it should be
> safe while those are depending only on MSVCRT.DLL

Can you include this in the documentation changes too?

Brad

[Dusan Paulovic]

> Looks reasonable. Can you please provide a patch?

I have provided resolutions for all the issues.

Ofcorse can provide some patch and documentation, but this thread was
just to inform contributors about some small changes in provided
packages which can make them compilable without deeper knowledge of
circumstances. But while I am not a contributor, all I can do is to
share what I ended with, but it is only personalized for our needs.
Issue around DEF file is common for all opensource projects providing
options to avoid some functionality. I would avoid DEF file and use
macros:

#ifdef _WIN32
#define DLLImport __declspec(dllimport)
#define DLLExport __declspec(dllexport)
#else
#define DLLImport
#define DLLExport
#endif

Dusan

[Brad Hards]

On Saturday 24 September 2011 20:18:26 Dusan Paulovic wrote:
> > Looks reasonable. Can you please provide a patch?
>
> I have provided resolutions for all the issues.

I recognise the resolutions, but I'd like to get those applied upstream. To
me, it seems better that the information is in the source tree, rather than
hoping people can find the right email thread. Ideally, it would all "just
work" for every platform.

> Ofcorse can provide some patch and documentation, but this thread was
> just to inform contributors about some small changes in provided
> packages which can make them compilable without deeper knowledge of
> circumstances. But while I am not a contributor, all I can do is to
> share what I ended with, but it is only personalized for our needs.

Your proposed resolutions seem generally applicable. As for not being a
contributor, I can only suggest that your work is already a valuable
contribution to the community. I ask for a patch to make sure that there is no
mis-interpretation of your intent. Its also easy to apply :-)

Brad

[a.fu...@lqt.it]

Hi Dusan,

> ... Issue around DEF file is common for all opensource

> projects providing options to avoid some functionality.
> I would avoid DEF file and use macros:
>

> #ifdef __WIN32

> #define DLLImport __declspec(dllimport)
> #define DLLExport __declspec(dllexport)
> #else
> #define DLLImport
> #define DLLExport
> #endif
>

the SpatiaLite own code already supports all this:
any "internal" function/symbol (not intended to be
externally visible/accessible) is declared to be
"static", e.g.:

static GEOSGeometry *
buildGeosPoints (const gaiaGeomCollPtr gaia);
static GEOSGeometry *
toGeosGeometry (const gaiaGeomCollPtr gaia);

----------

any other "external" export symbol is declared using
an appropriate prefix (an usual approach adopted by
many open source projects), e.g.:

#ifdef DLL_EXPORT
#define GAIAGEO_DECLARE __declspec(dllexport)
#else
#define GAIAGEO_DECLARE extern
#endif

GAIAGEO_DECLARE gaiaGeomCollPtr
gaiaAllocGeomColl (void);
GAIAGEO_DECLARE void
gaiaFreeGeomColl (gaiaGeomCollPtr p);

----------

this splendidly works when using the GCC compiler
(Linux, Mac Os X, MinGW on Windows).
but anyway this isn't enough when using the M$ own
compiler: AFAIK an explicit DEF file is absolutely
required in order to build any DLL on MSVC [nmake]
quite obviously, maintaining a further separate file
required by a single (proprietary) compiler/platform
is a boring task and an error-prone process.

As Brad already stated, supporting a CMake-based
build-system could be a valid long-term solution so
to support more "odd" proprietary compilers, and not
only the genuine free sw GCC (MinGW on Windows).

Anyway, any third-party contribution allowing for
a simplest and safest usage of MSVC is surely
welcome as an interim solution.

bye Sandro

[Dusan Paulovic]

> the SpatiaLite own code already supports all this:
> any "internal" function/symbol (not intended to be
> externally visible/accessible) is declared to be
> "static", e.g.:

Yes, I know, but it is probably not used by nmake tool because DEF
file seems to be superior to it.

> this splendidly works when using the GCC compiler
> (Linux, Mac Os X, MinGW on Windows).
> but anyway this isn't enough when using the M$ own
> compiler: AFAIK an explicit DEF file is absolutely
> required in order to build any DLL on MSVC [nmake]
> quite obviously, maintaining a further separate file
> required by a single (proprietary) compiler/platform
> is a boring task and an error-prone process.

AFAIK this is not issue in VS2005. All what is needed is to undefine /
def: from makefile.vc and define DLL_EXPORT in nmake.opt.

so, in makefile.vc's linker definition only (without /
def:libspatialite.def):
spatialite_i.lib: $(LIBOBJ)
link /debug /dll /out:$(SPATIALITE_DLL) \
/implib:spatialite_i.lib $(LIBOBJ) \
C:\OSGeo4W\lib\proj_i.lib C:\OSGeo4W\lib\geos_c_i.lib \
C:\OSGeo4w\lib\libiconv.dll.a C:\OSGeo4W\lib\SQLite3.lib
if exist $(SPATIALITE_DLL).manifest mt -manifest \
$(SPATIALITE_DLL).manifest -outputresource:$(SPATIALITE_DLL);2

and in namke.opt OPTFLAGS should look as follows:

OPTFLAGS= /nologo /Ox /fp:precise /W3 /MD /D_CRT_SECURE_NO_WARNINGS \
/D_LARGE_FILE=1 /D_FILE_OFFSET_BITS=64 /D_LARGEFILE_SOURCE=1 \
/DSQLITE_ENABLE_RTREE=1 /DYY_NO_UNISTD_H=1 /DDLL_EXPORT
#OPTFLAGS= /nologo /Zi /MD /Fdspatialite.pdb /DDLL_EXPORT

This is working fine with NMAKE tool without DEF file in VS2005 for
me...

Dusan

[a.fu...@lqt.it]

Hi Dusan,

thanks a lot for your useful suggestions.
I've accepted your proposed patches for the MSVC build
system: and now no silly .DEF file is any longer required.

I've performed a very limited testing using MSVC Express 2010;
anyway it would be surely useful if you could kindly perform
some further test.

FreeXL
======
from the SVN repository [r.17]:
svn co https://www.gaia-gis.it/svn/freexl freexl-svn
or download:
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/freexl-1.0.0.tar.gz
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/freexl-1.0.0.zip

libspatialite
=============
from the SVN repository [r.194]:
svn co https://www.gaia-gis.it/svn/libspatialite lispatialite-svn
or download:
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/libspatialite-3.0.0-beta1.tar.gz
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/libspatialite-3.0.0-beta1.zip
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/libspatialite-amalgamation-3.0.0-beta1.tar.gz
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/libspatialite-amalgamation-3.0.0-beta1.zip

spatialite-tools
================
from the SVN repository [r.50]:
svn co https://www.gaia-gis.it/svn/spatialite-tools patialite-tools-svn
or download:
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/spatialite-tools-3.0.0-beta1.tar.gz
http://www.gaia-gis.it/spatialite-3.0.0-BETA1/spatialite-tools-3.0.0-beta1.zip

bye Sandro

[Dusan Paulovic]

Hi Sandro, thanks for accepting my suggestions.
But I found another one issue. I have defined OMIT_GEOS and am getting
unresolved external symbol gaiaPolygonize referenced in
fnct_BuildArea.

May be there are more of issues like this...

Dusan

[a.furieri]

Hi Dusan,

you are absolutely right; and I've found similar problems when
defining OMIT_FREEL and OMIT_ICONV

now I've patched such issues (so I hope): you can download
the updated sources from the same URLs as in my previous post.

thanks for any further testing

bye Sandro