RC5 Experimental pre-release

[a.furieri]

Hi List,

an updated development snapshot is available:
http://www.gaia-gis.it/spatialite-2.4.0-5/index.html

PLEASE NOTE WELL: this one *really* is an experimental
version merely intended for testing and debugging purposes.
For any serious production task you are warmly suggested
to continue using the previous RC4 version.

--------------
- supporting SQLite 3.7.5

- supporting 'hot' GEOS 3.3.0 new features
please note: GEOS 3.3.0 is *not yet* released,
so this corresponds to the actual TRUNK (development)
snapshot. Final release of GEOS 3.3.0 is expected
during Spring 2011

- introducing SPATIALITE_HISTORY metadata table

- updated spatialite_gui-1.4.1 and spatialite CLI tools
* KML export
* identifying/cleaning duplicated rows

please, read the corresponding documentation.
A small-sized sample DB is available as well.

==============
this RC5 (Experimental release) strongly depends on the
not yet released GEOS 3.3.0

accordingly to this technical limitation, ONLY
WINDOWS EXECUTABLES (statically linked, no external
dependencies) are supported.

DON'T ASK FOR LINUX / MAC OS X BINARIES: they'll
never be available for this RC5-Experimental pre-release.

bye Sandro

[Noli Sicad]

Hi Sandro,

Thanks this release and for the new feature - Export KML / .dumpkml.

I am trying to build RC4 (library and spatialite-tools) for iOS 4.2
for iphone and ipad.

I got a lot of errors in RC4 with GEOS 3.2.

I am not using the make, but creating a XCode project with iOS SDK.

Do you where should I place this export "-CFLAGS=-DGEOS_AVANCED=1" in
Xcode Build?

Thanks.

Regards, Noli

> --
> You received this message because you are subscribed to the Google Groups
> "SpatiaLite Users" group.
> To post to this group, send email to spatiali...@googlegroups.com.
> To unsubscribe from this group, send email to
> spatialite-use...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/spatialite-users?hl=en.
>
>

[Noli Sicad]

Hi Sandro,

I am using this build script [1] for iOS

Where do I incorporate this,

export "-CFLAGS=-DGEOS_AVANCED=1"

in these scripts?

[1] https://github.com/mweisman/ShapeKit/tree/master/lib_src

Thanks.

Noli

[Noli Sicad]

Problems in compiling R4 and RC5 in Mac OS X 10.6.4 and iOS 4.2

Export wiithout - works.

export "CFLAGS=-DGEOS_AVANCED=1"

RC4 problem as reported in homebrew.

https://github.com/mxcl/homebrew/issuesearch?state=closed&q=spatialite+2.4.0#issue/3328

I already compiled GEOS 3.3 -trunk and Projection in Mac OS X 10.6.4
and iOS 4.2. However, I got problem with Proj_api.h bailing out in
compiling spatialite 2.4.0. RC5.

Here are logs below.

Noli

~~~~~~~~~~~~~
localhost:libspatialite-amalgamation-2.4.0 root# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... rm: a.out.dSYM: is
a directory
a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for inttypes.h... (cached) yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdint.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking build system type... i386-apple-darwin10.4.0
checking host system type... i386-apple-darwin10.4.0
checking for a sed that does not truncate output... /usr/bin/sed
checking for ld used by gcc... /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld)
is GNU ld... no
checking for /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld option to
reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm
checking how to recognize dependent libraries... pass_all
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 196608
checking command to parse /usr/bin/nm output from gcc object... rm:
conftest.dSYM: is a directory
ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
rm: conftest.dSYM: is a directory
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker
(/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared
libraries... yes
checking dynamic linker characteristics... darwin10.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld)
is GNU ld... no
checking whether the g++ linker
(/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker
(/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared
libraries... yes
checking dynamic linker characteristics... darwin10.4.0 dyld
(cached) (cached) checking how to hardcode library paths into
programs... immediate
appending configuration tag "F77" to libtool
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for working volatile... yes
checking whether lstat dereferences a symlink specified with a
trailing slash... no
checking whether lstat accepts an empty string... no
checking whether lstat dereferences a symlink specified with a
trailing slash... (cached) no
checking for working memcmp... yes
checking whether stat accepts an empty string... no
checking for strftime... yes
checking for memset... yes
checking for sqrt... yes
checking for strcasecmp... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for strstr... yes
checking for fdatasync... yes
checking for ftruncate... yes
checking for getcwd... yes
checking for gettimeofday... yes
checking for localtime_r... yes
checking for memmove... yes
checking for strerror... (cached) yes
checking proj_api.h usability... no
checking proj_api.h presence... no
checking for proj_api.h... no
configure: error: cannot find proj_api.h, bailing out
localhost:libspatialite-amalgamation-2.4.0 root#

[a.furieri]

Hi Noli,

my personal experience about Mac Os X is very
limited: and I never tested iOS.
so I haven't the slightest idea about all this;
anyway, some generic considerations:

XCode simply is an Apple-own GUI wrapper encapsulating
the good, old, universally widespread GNU gcc compiler

at least on Mac Os X (I have no idea about iOS)
you can simply open a standard command shell window:
and you'll immediately discover that Mac Os X
basically is a standard Unix (derived from FreeBSD).

Consequently the command line shell supports
the "classic" Unix/Linux tool-chain in a reasonably
standard fashion, i.e.:
./configure
make

I strongly suppose that XCode supports all this
in a "visual GUI" fashion: but my personal knowledge
stops here.
So the unique thing I can suggest you is:
please consult the appropriate Apple documentation.

bye Sandro

[a.furieri]

Hi Noli,

error #1: (proj_api.h)
=========

configure: error: cannot find proj_api.h, bailing out

the proj_api.h is the main PROJ.4 header;
./configure fails simply because is unable to
found this header files.

on my Mac testbed I personally use MacPorts:
and in order to let ./configure finding MacPort
packages I have to apply the following settings:

export "CFLAGS=-I/opt/local/include"
export "LDFLAGS=-L/opt/local/lib"
./configure --target=macosx
make



error #2 (homebrew libiconv)
========
more or less, the same as above.

you must specify --target=macosx when using
./configure on MacOsX

bye Sandro

[Noli Sicad]

Hi Sandro,

> on my Mac testbed I personally use MacPorts:
> and in order to let ./configure finding MacPort
> packages I have to apply the following settings:
>
> export "CFLAGS=-I/opt/local/include"
> export "LDFLAGS=-L/opt/local/lib"
> ./configure --target=macosx
> make

OK. You are using MacPort. This is the problem since regular Mac OS X
10.6 Snow Leopard install and link in /usr/local//include and
/usr/local/lib, respectively.

I was not watching the installation when creating libraries for iOS
and I was thinking install in Mac OS X, but it is not.

I manage to check the error now.

checking for strerror... (cached) yes

checking proj_api.h usability... yes
checking proj_api.h presence... yes
checking for proj_api.h... yes
checking for library containing pj_init_plus... -lproj
checking geos_c.h usability... no
checking geos_c.h presence... no
checking for geos_c.h... no
configure: error: cannot find geos_c.h, bailing out
localhost:libspatialite-amalgamation-2.4.0 root#

Compiling GEOS 3.3 -trunk now. I still going.....

I hope to solve this problem now.

BTW, iOS 4.2 is for Apple iPhone and iPad. I hoping to make Spatialite
using Route-Me and or MapKit in these devices.

Thanks. Noli

[Noli Sicad]

Hi Sandro,

Mac OS X 10.6 build for libspatialite and Spatilalite Tools were successful.

iOS 4.2 for iPhone and iPad attempt got problem.

Here is the problem.

checking for strerror... (cached) yes

checking proj_api.h usability... no
checking proj_api.h presence... yes
configure: WARNING: proj_api.h: present but cannot be compiled
configure: WARNING: proj_api.h: check for missing prerequisite headers?
configure: WARNING: proj_api.h: see the Autoconf documentation
configure: WARNING: proj_api.h: section "Present But Cannot Be Compiled"
configure: WARNING: proj_api.h: proceeding with the preprocessor's result
configure: WARNING: proj_api.h: in the future, the compiler will take precedence
configure: WARNING: ## ------------------------------- ##
configure: WARNING: ## Report this to a.fu...@lqt.it ##
configure: WARNING: ## ------------------------------- ##
checking for proj_api.h... yes
checking for library containing pj_init_plus... no
configure: error: 'libproj' is required but it doesn't seems to be
installed on this system.
localhost:libspatialite-amalgamation-2.4.0 root#

~~~~~~~~~~~~

libproj.a is available in the lib.

Probably you can have a look at GEOS and PROJ build scripts above this problem.

iOS build script can be found here.

https://github.com/mweisman/ShapeKit/blob/master/lib_src/build_ios

Thanks, Noli

[ma.ku]

I basically managed to compile the latest version of spatialite by
using the build scripts of the previos versions. The issue itself lies
at these missing options of the configure script:

--with-proj-include=DIR search for PROJ.4 headers in DIR
--with-proj-lib=DIR search for PROJ.4 lib in DIR
--with-geos-include=DIR search for GEOS headers in DIR
--with-geos-lib=DIR search for GEOS lib in DIR

Using these options the default include and library paths are ignored
and the cross-compiled libraries for arm6/arm7 could be included.
Without these the original headers and libraries for the compiling
platform get used.

I'm not sure where to file that issue to be addressed in the final
release of spatialite? Any ideas?

Good luck

On 2 Mrz., 14:45, Noli Sicad <nsi...@gmail.com> wrote:
> Hi Sandro,
>
> Mac OS X 10.6 build for libspatialite and Spatilalite Tools were successful.
>
> iOS 4.2 for iPhone and iPad attempt got problem.
>
> Here is the problem.
>
> checking for strerror... (cached) yes
> checking proj_api.h usability... no
> checking proj_api.h presence... yes
> configure: WARNING: proj_api.h: present but cannot be compiled
> configure: WARNING: proj_api.h:     check for missing prerequisite headers?
> configure: WARNING: proj_api.h: see the Autoconf documentation
> configure: WARNING: proj_api.h:     section "Present But Cannot Be Compiled"
> configure: WARNING: proj_api.h: proceeding with the preprocessor's result
> configure: WARNING: proj_api.h: in the future, the compiler will take precedence
> configure: WARNING:     ## ------------------------------- ##

> configure: WARNING:     ## Report this to a.furi...@lqt.it ##

[Noli Sicad]

Hi ma.ku

> I basically managed to compile the latest version of spatialite by
> using the build scripts of the previos versions. The issue itself lies
> at these missing options of the configure script:
>
> --with-proj-include=DIR search for PROJ.4 headers in DIR
> --with-proj-lib=DIR search for PROJ.4 lib in DIR
> --with-geos-include=DIR search for GEOS headers in DIR
> --with-geos-lib=DIR search for GEOS lib in DIR

Is it iin arch arm6/arm7 cross compiling tthat you manage to do this?
Or in Mac OS / Linux and Window?

> Using these options the default include and library paths are ignored
> and the cross-compiled libraries for arm6/arm7 could be included.
> Without these the original headers and libraries for the compiling
> platform get used.

>> https://github.com/mweisman/ShapeKit/blob/master/lib_src/build_ios

Using the build_os from above, I added this.

./configure \
--prefix="${prefix}" \
--host="${arch}-apple-darwin" \
--disable-shared \
--enable-static \
--with-proj-include="/UB/Spatialite240RC5/Proj470/src" \
--with-proj-lib="/UB/Spatialite240RC5/lib" \
--with-geos-include="/UB/Spatialite240RC5/GEOS33x/geos" \
--with-geos-lib=geos="/UB/Spatialite240RC5/lib" \
"$@" || exit

It did not work.
.

checking for strerror... (cached) yes
checking proj_api.h usability... no
checking proj_api.h presence... yes
configure: WARNING: proj_api.h: present but cannot be compiled
configure: WARNING: proj_api.h: check for missing prerequisite headers?
configure: WARNING: proj_api.h: see the Autoconf documentation
configure: WARNING: proj_api.h: section "Present But Cannot Be Compiled"
configure: WARNING: proj_api.h: proceeding with the preprocessor's result
configure: WARNING: proj_api.h: in the future, the compiler will take precedence
configure: WARNING: ## ------------------------------- ##

configure: WARNING: ## Report this to a.fu...@lqt.it ##

configure: WARNING: ## ------------------------------- ##
checking for proj_api.h... yes
checking for library containing pj_init_plus... no
configure: error: 'libproj' is required but it doesn't seems to be
installed on this system.

I think the solution to this problem is in GDAL script using Proj4 as
mentioned here.

http://trac.osgeo.org/gdal/ticket/1538

How to do this in spatialite?

It seems that this is the common problem in application using PROJ4
(e.g. GDAL and RGDAL) if it is static is enabled.

Hoping to find a solution to this problem.

Noli

[a.furieri]

Hi Ma.Ku,

please note: the --with-proj-include=DIR
(and alike) options where removed from the
./configure script simply because there is
no need at all in supporting them.

you can specify the appropriate DIRS simply
setting two standard environment variables:

export "CFLAGS=-I/usr/local/include"
export "LDFLAGS=-L/usr/local/lib"
./configure

(obviously you must replace the /usr/local
target accordingly to your actual dir layout)

the CFLAGS environment variable is the standard
GCC variable allowing to specify any further
dir_path to be searched for header files:
-I actually means "extra Include dir".

LDFLAG is exactly the same for libraries:
-L actually means "extra Libs dir"

and you can specify more than one dir, e.g.:
CFLAGS=-I/abc/include -I/xyz/include

then GCC will search any declared directory strictly
following the priority order you've defined: so this
one is the most generic (and most flexible) mechanism
we can implement to effectively support any "odd" dir
layout.

bye Sandro

[a.furieri]

Hi Noli,

using static-linkage strictly requires that any further
dependant library could actually be successfully located.

e.g. if LibA depends on LibB, simply setting a full path
pointing at LibA will fail: this is not enough, because
after this GCC will still be unable to locate LibB, and
consequently the linker will notice several unresolved
symbols (a fatal error condition).

Setting the external LDFLAGS variable as required and
appropriate will definitively resolve such issues in the
most painless way.
Because it's very probable that both LibA and LibB are
located into the same extra-libDir; and if this one
is not your case, it doesn't seems at all difficult
specifying (via LDFLAG) any further -L directive as
actually required by your specific layout.

bye Sandro

[markb]

Hi Sandro,

RC5 GUI is working well for me; SpatiaLite just keeps getting better, particularly as stability (including ops on enormous datasets) and speed (exceptional in WAL mode) are concerned. 

Don't forget about the ExtractMulti* (point, linestring & polygon) functions you went to the trouble of adding, they've been quite useful and necessary.  They are only mentioned in a group thread (http://groups.google.com/group/spatialite-users/browse_thread/thread/1310f3b2606367f5/e18853360a389b0b?lnk=gst&q=Intersection#e18853360a389b0b) and shown nowhere else (help dialog, online function list or syntax highlighter). 

Thanks for all the great work, looking forward to more greatness. 

-Mark