[GRASS-dev] winGRASS not built/broken

GRASS GRASS developer
,
1

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log
--------------------------------------------------
Started compilation: Tue Nov 7 21:30:33 2017
--
Errors in:
/c/msys32/usr/src/grass_trunk/raster/r.in.gdal
--
In case of errors please change into the directory with error and run
'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Tue Nov 7 22:05:34 2017

64bit:

last build:

WinGRASS-7.3.svn-r71641-404-Setup-x86_64.exe 08-Nov-2017 07:46 73M

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

2

On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log

Started compilation: Tue Nov 7 21:30:33 2017

Errors in:
/c/msys32/usr/src/grass_trunk/raster/r.in.gdal

The error is:
main.c:345: undefined reference to `GDALSetCacheMax64@4’

strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if “the maximum amount of memory that can be addressed by a process might be 2 GB or 3 GB, depending on the operating system capabilities.”

Falling back to GDALSetCacheMax for MS Windows (including 64 bit Windows) in r71677.

Markus M

–
In case of errors please change into the directory with error and run
‘make’.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.

Finished compilation: Tue Nov 7 22:05:34 2017

64bit:

last build:

WinGRASS-7.3.svn-r71641-404-Setup-x86_64.exe 08-Nov-2017 07:46 73M

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:

On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky hellik@web.de wrote:

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log

Started compilation: Tue Nov 7 21:30:33 2017

–

Errors in:

/c/msys32/usr/src/grass_trunk/raster/r.in.gdal

The error is:

main.c:345: undefined reference to `GDALSetCacheMax64@4’

strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the

maximum amount of memory that can be addressed by a process might be 2 GB

or 3 GB, depending on the operating system capabilities."

Falling back to GDALSetCacheMax for MS Windows (including 64 bit Windows)

in r71677.

The issue is probably that this build uses GDAL from OSGeo4W, into which GDAL has been configured and compiled with MSVC. Thus HAVE_LONG_LONG is not defined in cpl_config.h, and the GDALSetCacheMax64( GIntBig ) must evaluate to GDALSetCacheMax64 ( int ) when including from GRASS. I guess defining HAVE_LONG_LONG would solve the issue .

–

Spatialys - Geospatial professional services

http://www.spatialys.com

4

>that this build uses GDAL from OSGeo4W,

yes it uses OSGeo4W GDAL

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

5

On Sat, Nov 11, 2017 at 6:01 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:

On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log

Started compilation: Tue Nov 7 21:30:33 2017

–

Errors in:

/c/msys32/usr/src/grass_trunk/raster/r.in.gdal

The error is:

main.c:345: undefined reference to `GDALSetCacheMax64@4’

strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the

maximum amount of memory that can be addressed by a process might be 2 GB

or 3 GB, depending on the operating system capabilities."

Falling back to GDALSetCacheMax for MS Windows (including 64 bit Windows)

in r71677.

The issue is probably that this build uses GDAL from OSGeo4W, into which GDAL has been configured and compiled with MSVC. Thus HAVE_LONG_LONG is not defined in cpl_config.h, and the GDALSetCacheMax64( GIntBig ) must evaluate to GDALSetCacheMax64 ( int ) when including from GRASS. I guess defining HAVE_LONG_LONG would solve the issue .

If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), we can just as well use GDALSetCacheMax( int), the argument is the same ( int ).

Markus M

–

Spatialys - Geospatial professional services

http://www.spatialys.com

6

If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ),

My hypothesis might be wrong, but if it is true, then it wrongly evaluates to GDALSetCacheMax64 ( int ) when currently called by GRASS. If you define HAVE_LONG_LONG before including cpl_port.h or any other GDAL include files, that should work fine.

Similar issue, or more subtle ones, could also arise with other GDAL/OGR functions that use GIntBig (*). I guess the issue is only detected with GDALSetCacheMax64 since it uses CPL_STDCALL convention which apparently embeds the argument size in the symbol name, whereas C decl doesn’t do it.

I’m not sure why this would only occur with 32 bit builds, though. But this situation of using cpl_config.h generated for MSVC is kind of dangerous

Even

(*)

$ grep GIntBig ogr/ogr_api*.h

GIntBig CPL_DLL OGR_F_GetFieldAsInteger64( OGRFeatureH, int );

const GIntBig CPL_DLL *OGR_F_GetFieldAsInteger64List( OGRFeatureH, int, int * );

void CPL_DLL OGR_F_SetFieldInteger64( OGRFeatureH, int, GIntBig );

void CPL_DLL OGR_F_SetFieldInteger64List( OGRFeatureH, int, int, const GIntBig * );

GIntBig CPL_DLL OGR_F_GetFID( OGRFeatureH );

OGRErr CPL_DLL OGR_F_SetFID( OGRFeatureH, GIntBig );

OGRErr CPL_DLL OGR_L_SetNextByIndex( OGRLayerH, GIntBig );

OGRFeatureH CPL_DLL OGR_L_GetFeature( OGRLayerH, GIntBig ) CPL_WARN_UNUSED_RESULT;

OGRErr CPL_DLL OGR_L_DeleteFeature( OGRLayerH, GIntBig ) CPL_WARN_UNUSED_RESULT;

GIntBig CPL_DLL OGR_L_GetFeatureCount( OGRLayerH, int );

GIntBig CPL_DLL OGR_L_GetFeaturesRead( OGRLayerH );

–

Spatialys - Geospatial professional services

http://www.spatialys.com

7

On Sat, Nov 11, 2017 at 7:45 PM, Even Rouault <even.rouault@spatialys.com> wrote:

If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ),

My hypothesis might be wrong, but if it is true, then it wrongly evaluates to GDALSetCacheMax64 ( int ) when currently called by GRASS. If you define HAVE_LONG_LONG before including cpl_port.h or any other GDAL include files, that should work fine.

Stupid question: such a #define has only effect on compile time. If GDAL has been compiled without HAVE_LONG_LONG being defined, and then we define HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess? GRASS might then use a different GIntBig than GDAL.

Markus M

Similar issue, or more subtle ones, could also arise with other GDAL/OGR functions that use GIntBig (*). I guess the issue is only detected with GDALSetCacheMax64 since it uses CPL_STDCALL convention which apparently embeds the argument size in the symbol name, whereas C decl doesn’t do it.

I’m not sure why this would only occur with 32 bit builds, though. But this situation of using cpl_config.h generated for MSVC is kind of dangerous

Even

(*)

$ grep GIntBig ogr/ogr_api*.h

GIntBig CPL_DLL OGR_F_GetFieldAsInteger64( OGRFeatureH, int );

const GIntBig CPL_DLL *OGR_F_GetFieldAsInteger64List( OGRFeatureH, int, int * );

void CPL_DLL OGR_F_SetFieldInteger64( OGRFeatureH, int, GIntBig );

void CPL_DLL OGR_F_SetFieldInteger64List( OGRFeatureH, int, int, const GIntBig * );

GIntBig CPL_DLL OGR_F_GetFID( OGRFeatureH );

OGRErr CPL_DLL OGR_F_SetFID( OGRFeatureH, GIntBig );

OGRErr CPL_DLL OGR_L_SetNextByIndex( OGRLayerH, GIntBig );

OGRFeatureH CPL_DLL OGR_L_GetFeature( OGRLayerH, GIntBig ) CPL_WARN_UNUSED_RESULT;

OGRErr CPL_DLL OGR_L_DeleteFeature( OGRLayerH, GIntBig ) CPL_WARN_UNUSED_RESULT;

GIntBig CPL_DLL OGR_L_GetFeatureCount( OGRLayerH, int );

GIntBig CPL_DLL OGR_L_GetFeaturesRead( OGRLayerH );

–

Spatialys - Geospatial professional services

http://www.spatialys.com

8

On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:

Stupid question: such a #define has only effect on compile time. If GDAL

has been compiled without HAVE_LONG_LONG being defined, and then we define

HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess?

With MSVC, GIntBig expands to __int64 , which is equivalent in practice to long long.

–

Spatialys - Geospatial professional services

http://www.spatialys.com

9

Helmut Kudrnovsky wrote

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log
--------------------------------------------------
Started compilation: Tue Nov 7 21:30:33 2017
--
Errors in:
/c/msys32/usr/src/grass_trunk/raster/r.in.gdal
--
In case of errors please change into the directory with error and run
'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Tue Nov 7 22:05:34 2017

64bit:

last build:

WinGRASS-7.3.svn-r71641-404-Setup-x86_64.exe 08-Nov-2017 07:46 73M

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
_______________________________________________
grass-dev mailing list

grass-dev@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-dev

quick look into the log shows, the last compilation of binaries was still at
08-Nov-2017.

maybe there are other issues on the build server beside the ones found
yesterday?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

10

On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <even.rouault@spatialys.com> wrote:

On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:

Stupid question: such a #define has only effect on compile time. If GDAL

has been compiled without HAVE_LONG_LONG being defined, and then we define

HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess?

With MSVC, GIntBig expands to __int64 , which is equivalent in practice to long long.

MinGW also has __int64, therefore it would be great if you could apply

→
Index: port/cpl_port.h

— port/cpl_port.h (revision 40701)
+++ port/cpl_port.h (working copy)
@@ -219,7 +219,7 @@
/* 64bit support /
/ -------------------------------------------------------------------- */

-#if defined(WIN32) && defined(_MSC_VER)
+#if (defined(WIN32) && defined(_MSC_VER)) || defined(_WIN32)

#define VSI_LARGE_API_SUPPORTED
typedef __int64 GIntBig;
←

to gdal-trunk

Apart from that, GDALSetCacheMax64 could be replaced with CPLSetConfigOption( “GDAL_CACHEMAX”, “MB” ), that should avoid the issues with GIntBig on MS Windows.

Markus M

11

On Mon, Nov 13, 2017 at 10:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <even.rouault@spatialys.com> wrote:

On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:

Stupid question: such a #define has only effect on compile time. If GDAL

has been compiled without HAVE_LONG_LONG being defined, and then we define

HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess?

With MSVC, GIntBig expands to __int64 , which is equivalent in practice to long long.

MinGW also has __int64, therefore it would be great if you could apply

→
Index: port/cpl_port.h

— port/cpl_port.h (revision 40701)
+++ port/cpl_port.h (working copy)
@@ -219,7 +219,7 @@
/* 64bit support /
/ -------------------------------------------------------------------- */

-#if defined(WIN32) && defined(_MSC_VER)
+#if (defined(WIN32) && defined(_MSC_VER)) || defined(_WIN32)

#define VSI_LARGE_API_SUPPORTED
typedef __int64 GIntBig;
←

to gdal-trunk

wrong patch, it should rather be

→
Index: port/cpl_port.h

— port/cpl_port.h (revision 40701)
+++ port/cpl_port.h (working copy)
@@ -219,7 +219,7 @@
/* 64bit support /
/ -------------------------------------------------------------------- */

-#if defined(WIN32) && defined(_MSC_VER)
+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED
typedef __int64 GIntBig;
←

to account for different compile environments on Windows that have __int64

Markus M

Apart from that, GDALSetCacheMax64 could be replaced with CPLSetConfigOption( “GDAL_CACHEMAX”, “MB” ), that should avoid the issues with GIntBig on MS Windows.

Markus M

12

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* -------------------------------------------------------------------- */

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have __int64

Didn’t know that mingw had __int64 as wel.

Could you submit that as a pull request against https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2 mingw targets at

https://travis-ci.org/OSGeo/gdal ?

–

Spatialys - Geospatial professional services

http://www.spatialys.com

13

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com> wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* -------------------------------------------------------------------- */

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have __int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed available with MinGW.

Could you submit that as a pull request against https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2 mingw targets at
https://travis-ci.org/OSGeo/gdal ?

Done:
https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to __int64).

Markus M

14

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault even.rouault@spatialys.com

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Even

–

Spatialys - Geospatial professional services

http://www.spatialys.com

15

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com>

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Just to be save, for this, and if compiling with MS Visual Studio, I guess you need to modify port/cpl_config.h.vc to be aware of HAVE_LONG_LONG in order to create a compatible port/cpl_config.h (compatible if GDAL has been compiled with Visual Studio and another package is compiled with MinGW).

Markus M

16

On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com>

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Just to be save, for this, and if compiling with MS Visual Studio, I guess you need to modify port/cpl_config.h.vc to be aware of HAVE_LONG_LONG in order to create a compatible port/cpl_config.h (compatible if GDAL has been compiled with Visual Studio and another package is compiled with MinGW).

Wow, I see you have done that already!

Markus M

17

On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com>

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Just to be save, for this, and if compiling with MS Visual Studio, I guess you need to modify port/cpl_config.h.vc to be aware of HAVE_LONG_LONG in order to create a compatible port/cpl_config.h (compatible if GDAL has been compiled with Visual Studio and another package is compiled with MinGW).

Wow, I see you have done that already!

If long long is available with all Visual Studio versions supported by GDAL, you could simplify

#if defined(WIN32) || defined(HAVE_LONG_LONG)

to

#if defined(HAVE_LONG_LONG)

Sorry for the noise, it should be on the gdal-dev ml

Markus M

18

On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com>

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Just to be save, for this, and if compiling with MS Visual Studio, I guess you need to modify port/cpl_config.h.vc to be aware of HAVE_LONG_LONG in order to create a compatible port/cpl_config.h (compatible if GDAL has been compiled with Visual Studio and another package is compiled with MinGW).

Wow, I see you have done that already!

If long long is available with all Visual Studio versions supported by GDAL, you could simplify

#if defined(WIN32) || defined(HAVE_LONG_LONG)

to

#if defined(HAVE_LONG_LONG)

Thanks for fixing this in gdal-trunk!

However, there is still a small issue with the test for GIntBig in port/cpl_port.h:L226

#if HAVE_LONG_LONG

In cpl_config.h, HAVE_LONG_LONG is either defined and set to 1, or it is not defined. Therefore L226 should be

#if defined(HAVE_LONG_LONG)

or to be really sure that you have long long

#if defined(HAVE_LONG_LONG) && HAVE_LONG_LONG

but IMHO it is wrong to assume that HAVE_LONG_LONG is always defined and either zero or non-zero.

Markus M

19

On Thu, Nov 16, 2017 at 10:03 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.rouault@spatialys.com> wrote:

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.rouault@spatialys.com>

wrote:

→

Index: port/cpl_port.h

===================================================================

— port/cpl_port.h (revision 40701)

+++ port/cpl_port.h (working copy)

@@ -219,7 +219,7 @@

/* 64bit support */

/* --------------------------------------------------------------------

*/

-#if defined(WIN32) && defined(_MSC_VER)

+#if defined(WIN32) && (defined(_MSC_VER) || defined(MINGW32))

#define VSI_LARGE_API_SUPPORTED

typedef __int64 GIntBig;

←

to account for different compile environments on Windows that have

__int64

Didn’t know that mingw had __int64 as wel.

According to the documentation, yes. I tested, and __int64 is indeed

available with MinGW.

Could you submit that as a pull request against

https://github.com/OSGeo/gdal so we can check that this doesn’t break our 2

mingw targets at

https://travis-ci.org/OSGeo/gdal ?

Done:

https://github.com/OSGeo/gdal/pull/262

Regarding integer types with MSC: why is HAVE_LONG_LONG not defined in

cpl_config.h for WIN32? There is a long long in WIN32 (equivalent to

__int64).

I guess this dates back to ancient times, like Visual Studio C++ 6.0, where long long wasn’t available, but we no longer support that compiler. Apparently long long is available since VS 2005

I’m probably going to simplify things and have one single case for #if defined(WIN32) || defined(HAVE_LONG_LONG)

Just to be save, for this, and if compiling with MS Visual Studio, I guess you need to modify port/cpl_config.h.vc to be aware of HAVE_LONG_LONG in order to create a compatible port/cpl_config.h (compatible if GDAL has been compiled with Visual Studio and another package is compiled with MinGW).

Wow, I see you have done that already!

If long long is available with all Visual Studio versions supported by GDAL, you could simplify

#if defined(WIN32) || defined(HAVE_LONG_LONG)

to

#if defined(HAVE_LONG_LONG)

Thanks for fixing this in gdal-trunk!

However, there is still a small issue with the test for GIntBig in port/cpl_port.h:L226

#if HAVE_LONG_LONG

In cpl_config.h, HAVE_LONG_LONG is either defined and set to 1, or it is not defined. Therefore L226 should be

#if defined(HAVE_LONG_LONG)

or to be really sure that you have long long

#if defined(HAVE_LONG_LONG) && HAVE_LONG_LONG

but IMHO it is wrong to assume that HAVE_LONG_LONG is always defined and either zero or non-zero.

Please ignore the above comment

#if HAVE_LONG_LONG

works just fine

Markus M