[WIN] Error Makefile: LineIntersector.cpp

[taibc]

Hi,

I am trying to build GEOS (Version 3.3.5) on Window 7. But I got the bellow error:

algorithm\LineIntersector.cpp(671) : error C3861: 'isnan': identifier not found algorithm\LineIntersector.cpp(672) : error C3861: 'isnan': identifier not found algorithm\LineIntersector.cpp(680) : error C3861: 'isnan': identifier not found algorithm\LineIntersector.cpp(681) : error C3861: 'isnan': identifier not found algorithm\LineIntersector.cpp(736) : error C3861: 'isnan': identifier not found algorithm\LineIntersector.cpp(737) : error C3861: 'isnan': identifier not found NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI N\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI N\nmake.EXE"' : return code '0x2' Stop.

Do you know how to fix it ?

Thanks and regards,

Tai

[djay]

Dear Tai, you may try adding the followig lines (on line 18) in your local include/geos/export.h file:

#ifndef isnan
#define isnan(x) _isnan(x)
#endif

Then re-run nmake command and it should successfully compile.

[djay]

Even if the compilation process succeed on window platforms using this method mentionned it is not a good solution as you will face many issues linked to TopologyException.

The correct way to fix this issue is to edit the platform.h file in headers/geos or include/geos depending on the version you use (3.2.3 or 3.3.5).

To get a successfull build and a working copy of GEOS dlls, I defined HAVE_INT64_T_64 on line 6, undefined HAVE_LONG_INT_64 on line 9 and also HAVE_ISNAN on line 24.

This fixed issue for both 3.2.3 and 3.3.5 versions. Note that problem was similar when trying using 3.2.3 version.

[strk]

Is there anything to be done here or should we close this ? Personally I've no interest in supporting windows builds so it'd take someone willing to contribute patches for it to be taken care of

[djay]

Well, to be frank I guess that there is still some problem when compiling GEOS the way I did with the mentionned modifications but I didn't get time to investigate deeper by now. I would like to find a definitive solution to solve this issue but I understand clearly the lack of interrest for windows platforms.

[digimap2k]

OK so I have a little more information on this for anyone still reading. The fixes listed above are all variously doing what is already done in "platform.h.vc" within the source distribution so the bigger question is why this isn't being used.

The answer to that lies in the "src/nmake.vc" makefile. This includes the command to copy the platform specific header over platform.h. It is failing to execute. As far as I can tell it is down to the makefile label used for this which is a full path to the platform file. When I change that to use a simple label like "platform:" then it all works perfectly. So I can only presume that something in the current label of "$(GEOS_ROOT)\include\geos\platform.h:" isn't working in nmake. Seems reasonable to me.

My preferred fix would be a makefile section called "headers:" which copied both the platform and version header files.

headers:

$(CP) $(GEOS_ROOT)\include\geos\platform.h.vc $(GEOS_ROOT)\include\geos\platform.h if not exist $(GEOS_ROOT)\include\geos\version.h $(CP) $(GEOS_ROOT)\include\geos\version.h.vc $(GEOS_ROOT)\include\geos\version.h

Then add that to the $(LIBNAME) line as

$(LIBNAME): headers ..\capi\geos_c.h $(OBJ)

[digimap2k]

Updated makefile to fix problem where headers not copied.

[digimap2k]

And one more update, I just spotted the "autogen.bat" in the windows build instructions which is manually copying these header files presumably because the makefile is failing to do so. I've rolled the capi header into the makefile fix (attached) and with this modified makefile I can build 3.3.8 on Windows with VC9.0 without needing the autogen batch file and with no errors.

[robe]

I don't like your fix. The issue I see is you have hard-coded a lot of the OBJ stuff in your Makefile.vc which requires us to nurse this file separate from the other files. Please use CMake from now on for VS development if you are dissatisfied with using autogen.bat instructions here http://trac.osgeo.org/geos/wiki/BuildingOnWindowsWithCMake

[robe]

Oops sorry. I realize now I was comparing this to the wrong makefile.vc, Generally its best to provide a diff/patch. I'll take a look at this again once I've applied another ticket makefile.vc diff.

[robe]

At a quick glance I suspect this might be issue that wamerdam brought up that platform.h is being distributed and ergo platform.h.vc is not being used.

ergo I'm gong to guess this is a dupe of #601 which I have patched.

If you feel this is not a dupe, then feel free to reopen. I personally prefer to build with cmake now and would encourage anyone to do so as well. I don't use VS for building so can't test this.