winGRASS not built/broken

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

winGRASS not built/broken

Helmut Kudrnovsky
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <[hidden email]> 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Even Rouault-2

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

> On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Helmut Kudrnovsky
 >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
_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3
In reply to this post by Even Rouault-2


On Sat, Nov 11, 2017 at 6:01 PM, Even Rouault <[hidden email]> wrote:

>
> On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:
>
> > On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Even Rouault-2

 

> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Sat, Nov 11, 2017 at 7:45 PM, Even Rouault <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Even Rouault-2

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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Helmut Kudrnovsky
In reply to this post by Helmut Kudrnovsky
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
_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3
In reply to this post by Even Rouault-2


On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <[hidden email]> 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, GDALSetCacheMax[64](bytes) could be replaced with CPLSetConfigOption( "GDAL_CACHEMAX", "MB" ), that should avoid the issues with GIntBig on MS Windows.

Markus M


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Mon, Nov 13, 2017 at 10:30 PM, Markus Metz <[hidden email]> wrote:

>
>
>
> On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <[hidden email]> 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, GDALSetCacheMax[64](bytes) could be replaced with CPLSetConfigOption( "GDAL_CACHEMAX", "MB" ), that should avoid the issues with GIntBig on MS Windows.
>
> Markus M
>

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Even Rouault-2

> -->

> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]> 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:

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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Even Rouault-2

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

> On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>

>

> 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <[hidden email]> wrote:

>
> On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
>
> > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>
>
> >
>
> > 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <[hidden email]> wrote:

>
>
>
> On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <[hidden email]> wrote:
> >
> > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
> >
> > > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>
> >
> > >
> >
> > > 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <[hidden email]> wrote:

>
>
>
> On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <[hidden email]> wrote:
> >
> >
> >
> > On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <[hidden email]> wrote:
> > >
> > > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
> > >
> > > > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>
> > >
> > > >
> > >
> > > > 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

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz <[hidden email]> wrote:

>
>
>
> On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <[hidden email]> wrote:
> >
> >
> >
> > On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <[hidden email]> wrote:
> > >
> > >
> > >
> > > On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <[hidden email]> wrote:
> > > >
> > > > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
> > > >
> > > > > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>
> > > >
> > > > >
> > > >
> > > > > 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


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: winGRASS not built/broken

Markus Metz-3


On Thu, Nov 16, 2017 at 10:03 AM, Markus Metz <[hidden email]> wrote:

>
>
>
> On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz <[hidden email]> wrote:
> >
> >
> >
> > On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <[hidden email]> wrote:
> > >
> > >
> > >
> > > On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <[hidden email]> wrote:
> > > > >
> > > > > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
> > > > >
> > > > > > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <[hidden email]>
> > > > >
> > > > > >
> > > > >
> > > > > > 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

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev