trunk build failed with MinGW

[sanak]

I had tried to build trunk source with MinGW at this weekend, and some error occurred.

1. 'finite' function is not defined in MinGW

/// error message ///
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../source/headers -I../../../source/headers/geos -I../../../source/headers -g -O2 -DGEOS_INLINE -pedantic -Wall -ansi -Wno-long-long -ffloat-store -MT IndexedPointInAreaLocator.lo -MD -MP -MF .deps/IndexedPointInAreaLocator.Tpo -c IndexedPointInAreaLocator.cpp  -DDLL_EXPORT -DPIC -o .libs/IndexedPointInAreaLocator.o
In file included from ../../../source/headers/geos/geom/Geometry.h:26,
                 from IndexedPointInAreaLocator.cpp:18:
../../../source/headers/geos/platform.h: In function `bool isFinite(double)':
../../../source/headers/geos/platform.h:64: error: `finite' was not declared in this scope
../../../source/headers/geos/platform.h:64: warning: unused variable 'finite'
make[4]: *** [IndexedPointInAreaLocator.lo] Error 1

I had modified source/headers/geos/platform.h.in(see attached patch), but I don't know that my modification is the valid way, so please check my patch carefully. The following topic may be relate to this problem.  http://lists.osgeo.org/pipermail/geos-devel/2006-June/002350.html

2.dllimport error

/// error message ///
HCoordinate.cpp:233: warning: non-inline function 'void geos::algorithm::HCoordinate::getCoordinate(geos::geom::Coordinate&) const' is defined after prior declaration as dllimport: attribute ignored
HCoordinate.cpp:233: warning: 'void geos::algorithm::HCoordinate::getCoordinate(geos::geom::Coordinate&) const' defined locally after being referenced with dllimport linkage
HCoordinate.cpp: In constructor `geos::algorithm::HCoordinate::HCoordinate(const geos::geom::Coordinate&)':
HCoordinate.cpp:130: internal compiler error: in rest_of_handle_final, at toplev.c:2067

I had modified source/headers/geos/export.h(see attached patch). I think that if no preprocessor definition (like GEOS_DLL_XXX), GEOS_DLL should be defined as null word, but I hope someone check this.

NOTICE I had set MinGW environment referring to the following site,  http://trac.osgeo.org/postgis/wiki/UsersWikiWinCompile and, modify some files.

• MinGW(g++-3.4.5)

  \MinGW\include\c++\3.4.5\cwchar
  ...comment out import (v)swprintf.
  

  using ::putwchar;
  //using ::swprintf; // delete
  using ::swscanf;
  using ::ungetwc;
  using ::vfwprintf;
#if _GLIBCXX_HAVE_VFWSCANF
  using ::vfwscanf;
#endif
  //using ::vswprintf; // delete
#if _GLIBCXX_HAVE_VSWSCANF
  using ::vswscanf;
#endif

• libtool(2.2.4)

  \libltdl\config\ltmain.sh
  ... add include <process.h>
  

#ifdef _MSC_VER
# include <direct.h>
# include <process.h>
# include <io.h>
# define setmode _setmode
#else
# include <unistd.h>
# include <stdint.h>
# ifdef __CYGWIN__
#  include <io.h>
# endif
/* <-- add for _P_WAIT */
# ifdef __MINGW32__
#  include <process.h>
# endif
/* --> */
#endif

Regards,

Sanak.

[sanak]

TortoiseSVN(Japanese)

[strk]

Ragi, could you check this patch doesn't break your MSVC builds please ?

[strk]

On behalf of ragi:

If you are going to do the changes to the preprocessor definitions to be [GEOS_EXPORT and GEOS_IMPORT] instead of [GEOS_DLL_LIBRARY_STATIC and GEOS_DLL_LIBRARY], this does make sense to me from a naming convention point of view. However, the Visual Studio studio project's preprocessor section needs to also be changed or the symbols will not be exported.

Sanak, can you provide another patch for the VS project too, or keep the old naming ?

Anyone with more trac knowledge: how to give ragi "append" privileges here ?

[sanak]

strk, Ragi,

Thanks for your reply. I will create another patch for the VS project at this weekend.

[sanak]

TortoiseSVN(Double Byte Character Set)

[sanak]

strk, Ragi

I had created the patch for the VS2009 project, but another treatments will be necessary for VS2008(#268) and Makefile.vc by this patch.

So I will create new ticket for Makefile.vc problem, and modify #268 ticket later.

I wish GEOS supported cmake build system like QGis..

Regards,

[strk]

So, to recap: should I apply both fix-mingw.patch AND fix-export+msvc90.patch against current trunk (r2607) and then wait for a new patch on #268 ?

[sanak]

strk,

Yes.

Current trunk(r2607) windows build results are as follows.

msvc90	msvc80	nmake	mingw
o	x(#268)	x	x(#273)

(x:dllimport error .etc)

After you apply above patches, the results will change as follows.

msvc90	msvc80	nmake	mingw
o	x(#268)	x(*1)	o

(x(#268):sync problem, x(*1):dllexport for geos_c.dll)

I will create new patch for msvc80(#268), and create new ticket for nmake(Makefile.vc) build problem, after that.

[strk]

I committed the fix-mingw.patch but fix-export+msvc90.patch didn't apply cleanly. Could you try to reproduce the latter against r2608 please (could be the multi-byte format maybe?).

[sanak]

TortoiseSVN(modify DBCS to ASCII)

[sanak]

strk,

Ok, I had attached the new patch(fix-msvc90-only.patch).

[strk]

Keeps failing, no idea why:

(Stripping trailing CRs from patch.) patching file build/msvc90/geos_c_dll/geos_c_dll.vcproj Hunk #1 FAILED at 42. Hunk #2 FAILED at 119. 2 out of 2 hunks FAILED -- saving rejects to file build/msvc90/geos_c_dll/geos_c_dll.vcproj.rej (Stripping trailing CRs from patch.) patching file build/msvc90/geos_lib/geos_lib.vcproj Hunk #1 FAILED at 42. Hunk #2 FAILED at 109. Hunk #3 FAILED at 1601. 3 out of 3 hunks FAILED -- saving rejects to file build/msvc90/geos_lib/geos_lib.vcproj.rej (Stripping trailing CRs from patch.) patching file build/msvc90/geos_unit/geos_unit.vcproj Hunk #1 FAILED at 42. Hunk #2 FAILED at 121. Hunk #3 FAILED at 510. Hunk #4 FAILED at 562. Hunk #5 FAILED at 586. 5 out of 5 hunks FAILED -- saving rejects to file build/msvc90/geos_unit/geos_unit.vcproj.rej

[sanak]

Ubuntu 9.0.4 NBR svn diff(Japanese)

[sanak]

strk,

Sorry, I don't know why it fails. I had recreated the patch(fix-msvc90-only2.patch) by Ubuntu svn diff command, so please try this file.

Regards,

Keeps failing, no idea why:

[strk]

Ok, fix-msvc90-only2.patch applied cleanly and was committed in r2609. Let me know if all is fine for this bug so I'll close and we can move to #268 for the rest.

[sanak]

strk,

The build results are as follows.
mingw => ok (build only.(except "make check"))
msvc90 => ok

So, I think this ticket can be closed.

Regards,

[mloskot]

Replying to sanak:

I wish GEOS supported cmake build system like QGis..

If you're still interested, please take a look at ticket #317 - feedback, testing and improvements are strongly welcome. Note, I'm going to remove manually maintained Visual Studio projects as soon as I'm happy with the CMake configuration, very likely for milestone:3.3.0

...who's next to CMake'ing, PostGIS? :-P

[geosanak]

Replying to mloskot:

I wish GEOS supported cmake build system like QGis..

If you're still interested, please take a look at ticket #317 - feedback, testing and improvements are strongly welcome. Note, I'm going to remove manually maintained Visual Studio projects as soon as I'm happy with the CMake configuration, very likely for milestone:3.3.0

Mateusz,

Thanks for your great work!
I will try this new build system at this weekend.

Regards,