#273 closed defect (fixed)
trunk build failed with MinGW
Reported by: | sanak | Owned by: | strk |
---|---|---|---|
Priority: | major | Milestone: | 3.2.0 |
Component: | Build/Install | Version: | main |
Severity: | Unassigned | Keywords: | mingw |
Cc: | ragi@… |
Description (last modified by )
I had tried to build trunk source with MinGW at this weekend, and some error occurred.
- '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.
Attachments (4)
Change History (21)
by , 15 years ago
Attachment: | fix-mingw.patch added |
---|
comment:1 by , 15 years ago
Owner: | changed from | to
---|
comment:2 by , 15 years ago
Cc: | added |
---|
Ragi, could you check this patch doesn't break your MSVC builds please ?
follow-ups: 4 5 comment:3 by , 15 years ago
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 ?
comment:4 by , 15 years ago
strk, Ragi,
Thanks for your reply. I will create another patch for the VS project at this weekend.
follow-up: 15 comment:5 by , 15 years ago
follow-up: 7 comment:6 by , 15 years ago
comment:7 by , 15 years ago
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.
comment:8 by , 15 years ago
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?).
follow-up: 11 comment:10 by , 15 years ago
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
comment:11 by , 15 years ago
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:
follow-up: 13 comment:12 by , 15 years ago
comment:13 by , 15 years ago
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,
comment:14 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
follow-up: 17 comment:15 by , 15 years ago
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
comment:16 by , 15 years ago
Description: | modified (diff) |
---|
comment:17 by , 14 years ago
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,
TortoiseSVN(Japanese)