Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Barry DeZonia via gdal-dev 
Greg, you might want to CC Evan into this email chain.

On Mon, Jun 24, 2024 at 1:53 PM Greg Troxel via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Scott via gdal-dev  writes:
>
> > On debian 12:
> >
> > /usr/include/c++/12/cstdlib, line 75. Context:
> >
> > // Need to ensure this finds the C library's  not a libstdc++
> > // wrapper that might already be installed later in the include search
> path.
> > #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> > #include_next 
> > #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> > #include 
>
> Is this then a Debian/gcc12 bug?
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Greg Troxel via gdal-dev 
Scott via gdal-dev  writes:

> On debian 12:
>
> /usr/include/c++/12/cstdlib, line 75. Context:
>
> // Need to ensure this finds the C library's  not a libstdc++
> // wrapper that might already be installed later in the include search path.
> #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> #include_next 
> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> #include 

Is this then a Debian/gcc12 bug?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 

On debian 12:

/usr/include/c++/12/cstdlib, line 75. Context:

// Need to ensure this finds the C library's  not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include 

...

On 6/24/24 11:24, Greg Troxel via gdal-dev wrote:

I egreped over the gdal 3.9.1rc2 sources and do not find this
include_next stdlib at all.

   $ egrep -R include_next.*stdlib .

Please explain where you think it is in the sources.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Barry DeZonia via gdal-dev 
Yeah, I didn't know about this pragma directive at all. A simple summary
about it is here (including disclaimers on use).

https://stackoverflow.com/questions/10261382/why-would-one-use-include-next-in-a-project

On Mon, Jun 24, 2024 at 1:20 PM Greg Troxel via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Scott via gdal-dev  writes:
>
> > #include_next is part of the c++ version 12. You can find it's usage
> >  here on debian 12:
> >
> > /usr/include/c++/12/cstdlib, line 75
>
> I think that's gcc 12, not C++12 which is not a thing :-)
>
> It being used in an internal header supplied by the compiler is one
> thing.  I do not understand how an include of stdlib in a user program
> can do that sensibly.  It's supposed to mean that only things in the
> include path after this file that was found, are to be searched.
> That's very tricky and requires assumptions/checks about the include
> order, and cmake does not seem to guarantee a lot in that department.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Greg Troxel via gdal-dev 
I egreped over the gdal 3.9.1rc2 sources and do not find this
include_next stdlib at all.

  $ egrep -R include_next.*stdlib .

Please explain where you think it is in the sources.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Greg Troxel via gdal-dev 
Scott via gdal-dev  writes:

> #include_next is part of the c++ version 12. You can find it's usage
>  here on debian 12:
>
> /usr/include/c++/12/cstdlib, line 75

I think that's gcc 12, not C++12 which is not a thing :-)

It being used in an internal header supplied by the compiler is one
thing.  I do not understand how an include of stdlib in a user program
can do that sensibly.  It's supposed to mean that only things in the
include path after this file that was found, are to be searched.
That's very tricky and requires assumptions/checks about the include
order, and cmake does not seem to guarantee a lot in that department.

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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 
#include_next is part of the c++ version 12. You can find it's usage 
here on debian 12:


/usr/include/c++/12/cstdlib, line 75


On 6/24/24 11:03, Scott via gdal-dev wrote:
Yes, I saw that. It's the default code. I tried changing it to just 
'include' early on and got a whole new set of errors.


Changing the default source code without an understanding of the bigger 
picture leaves me a bit out of my element, though.


Thanks!

On 6/24/24 10:57, Barry DeZonia wrote:
Scott, is it that you are using #include_next instead of #include? 
#include_next makes assumptions about the environment that #include 
does not.


On Mon, Jun 24, 2024 at 12:53 PM Scott via gdal-dev 
mailto:gdal-dev@lists.osgeo.org>> wrote:


    Thanks for the docker instructions. It built nice and clean.

    That still leaves the question, in my environment, why do all the 
apps

    except gdalsrsinfo build? I seriously doubt stdlib.h is only used by
    gdalsrsinfo.

    Thanks for the help! I'll try and figure it out.

    On 6/24/24 10:25, Even Rouault wrote:
 >
 > Le 24/06/2024 à 19:15, Scott a écrit :
 >> It's Debian 12. No, it's not clean. It's had several versions of
    gdal,
 >> et al, on it.
 >>
 >> It appears srsinfo in not finding stdlib.h and all the other
    apps do,
 >> which is the part I found odd.
 >>
 >> Docker is not the environment I'm building in.
 >
 > yes, but that's the most convenient way for me to try to
    reproduce all
 > the diverse environments people can use
 >
 > Just trying the following works fine for me:
 >
 > docker run --rm -it -v /home/even/gdal/3.9:/home/even/gdal/3.9
    debian:12
 >
 > (inside it)
 >
 > cd /home/even/gdal/3.9/build_debian_12/
 > apt update && apt install cmake g++ make libproj-dev
 > cmake ..
 > make -j$(nproc)
 >
 >>
 >> Thanks!
 >>
 >> On 6/24/24 10:01, Even Rouault wrote:
 >>> Hi,
 >>>
 >>> What is the version of your Debian system ? Is it "clean" ? Can
    you
 >>> for example reproduce in the corresponding debian:XXX docker 
image?

 >>>
 >>>

https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+ " shows that this error message is quite common, although on quick reading, I couldn't spot a common point/solution between all those occurrences

 >>>
 >>> Even
 >>>
 >>> Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
  When building 3.9.1 rc1/r2 I get the following when linking. 
If I

  comment srsinfo out of the makefile, all other gdal/ogr apps
    build
  fine with no issues.
 
  uname -a:
  Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian
    6.1.90-1
  (2024-05-03) x86_64 GNU/Linux
 
  Thanks!
 
  Build output below:
 
  [ 98%] Building CXX object
  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o
  In file included from
    /usr/include/c++/12/ext/string_conversions.h:41,
   from
    /usr/include/c++/12/bits/basic_string.h:3960,
   from /usr/include/c++/12/string:53,
   from
  /export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
   from
  /export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
   from
  /export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
  /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No 
such

  file or directory
     75 | #include_next 
    |   ^~
  compilation terminated.
  make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76:
  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
  make[1]: *** [CMakeFiles/Makefile2:10247:
  apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2
  make: *** [Makefile:146: all] Error 2
 
  ___
  gdal-dev mailing list
  gdal-dev@lists.osgeo.org 
  https://lists.osgeo.org/mailman/listinfo/gdal-dev
    
 >>>
    ___
    gdal-dev mailing list
    gdal-dev@lists.osgeo.org 
    https://lists.osgeo.org/mailman/listinfo/gdal-dev
    


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

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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 
Yes, I saw that. It's the default code. I tried changing it to just 
'include' early on and got a whole new set of errors.


Changing the default source code without an understanding of the bigger 
picture leaves me a bit out of my element, though.


Thanks!

On 6/24/24 10:57, Barry DeZonia wrote:
Scott, is it that you are using #include_next instead of #include? 
#include_next makes assumptions about the environment that #include does 
not.


On Mon, Jun 24, 2024 at 12:53 PM Scott via gdal-dev 
mailto:gdal-dev@lists.osgeo.org>> wrote:


Thanks for the docker instructions. It built nice and clean.

That still leaves the question, in my environment, why do all the apps
except gdalsrsinfo build? I seriously doubt stdlib.h is only used by
gdalsrsinfo.

Thanks for the help! I'll try and figure it out.

On 6/24/24 10:25, Even Rouault wrote:
 >
 > Le 24/06/2024 à 19:15, Scott a écrit :
 >> It's Debian 12. No, it's not clean. It's had several versions of
gdal,
 >> et al, on it.
 >>
 >> It appears srsinfo in not finding stdlib.h and all the other
apps do,
 >> which is the part I found odd.
 >>
 >> Docker is not the environment I'm building in.
 >
 > yes, but that's the most convenient way for me to try to
reproduce all
 > the diverse environments people can use
 >
 > Just trying the following works fine for me:
 >
 > docker run --rm -it -v /home/even/gdal/3.9:/home/even/gdal/3.9
debian:12
 >
 > (inside it)
 >
 > cd /home/even/gdal/3.9/build_debian_12/
 > apt update && apt install cmake g++ make libproj-dev
 > cmake ..
 > make -j$(nproc)
 >
 >>
 >> Thanks!
 >>
 >> On 6/24/24 10:01, Even Rouault wrote:
 >>> Hi,
 >>>
 >>> What is the version of your Debian system ? Is it "clean" ? Can
you
 >>> for example reproduce in the corresponding debian:XXX docker image?
 >>>
 >>>
https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+ 
"
 shows that this error message is quite common, although on quick reading, I couldn't spot 
a common point/solution between all those occurrences
 >>>
 >>> Even
 >>>
 >>> Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
  When building 3.9.1 rc1/r2 I get the following when linking. If I
  comment srsinfo out of the makefile, all other gdal/ogr apps
build
  fine with no issues.
 
  uname -a:
  Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.90-1
  (2024-05-03) x86_64 GNU/Linux
 
  Thanks!
 
  Build output below:
 
  [ 98%] Building CXX object
  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o
  In file included from
/usr/include/c++/12/ext/string_conversions.h:41,
   from
/usr/include/c++/12/bits/basic_string.h:3960,
   from /usr/include/c++/12/string:53,
   from
  /export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
   from
  /export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
   from
  /export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
  /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such
  file or directory
     75 | #include_next 
    |   ^~
  compilation terminated.
  make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76:
  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
  make[1]: *** [CMakeFiles/Makefile2:10247:
  apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2
  make: *** [Makefile:146: all] Error 2
 
  ___
  gdal-dev mailing list
  gdal-dev@lists.osgeo.org 
  https://lists.osgeo.org/mailman/listinfo/gdal-dev

 >>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Greg Troxel via gdal-dev 
Barry DeZonia via gdal-dev  writes:

> Scott, is it that you are using #include_next instead of #include?
> #include_next makes assumptions about the environment that #include does
> not.

And, stdlib.h is very much required by POSIX.  On Debian 12 amd64,
/usr/include/stdlib.h is there, just as expected/required.

#include_next is new to me.   Using it seems irregular, and using it for
 stdlib seems wrong, from a posix-compliance point of view.

Is this in the gdal sources?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Barry DeZonia via gdal-dev 
Scott, is it that you are using #include_next instead of #include?
#include_next makes assumptions about the environment that #include does
not.

On Mon, Jun 24, 2024 at 12:53 PM Scott via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Thanks for the docker instructions. It built nice and clean.
>
> That still leaves the question, in my environment, why do all the apps
> except gdalsrsinfo build? I seriously doubt stdlib.h is only used by
> gdalsrsinfo.
>
> Thanks for the help! I'll try and figure it out.
>
> On 6/24/24 10:25, Even Rouault wrote:
> >
> > Le 24/06/2024 à 19:15, Scott a écrit :
> >> It's Debian 12. No, it's not clean. It's had several versions of gdal,
> >> et al, on it.
> >>
> >> It appears srsinfo in not finding stdlib.h and all the other apps do,
> >> which is the part I found odd.
> >>
> >> Docker is not the environment I'm building in.
> >
> > yes, but that's the most convenient way for me to try to reproduce all
> > the diverse environments people can use
> >
> > Just trying the following works fine for me:
> >
> > docker run --rm -it -v /home/even/gdal/3.9:/home/even/gdal/3.9 debian:12
> >
> > (inside it)
> >
> > cd /home/even/gdal/3.9/build_debian_12/
> > apt update && apt install cmake g++ make libproj-dev
> > cmake ..
> > make -j$(nproc)
> >
> >>
> >> Thanks!
> >>
> >> On 6/24/24 10:01, Even Rouault wrote:
> >>> Hi,
> >>>
> >>> What is the version of your Debian system ? Is it "clean" ? Can you
> >>> for example reproduce in the corresponding debian:XXX docker image?
> >>>
> >>>
> https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+;
> shows that this error message is quite common, although on quick reading, I
> couldn't spot a common point/solution between all those occurrences
> >>>
> >>> Even
> >>>
> >>> Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
>  When building 3.9.1 rc1/r2 I get the following when linking. If I
>  comment srsinfo out of the makefile, all other gdal/ogr apps build
>  fine with no issues.
> 
>  uname -a:
>  Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1
>  (2024-05-03) x86_64 GNU/Linux
> 
>  Thanks!
> 
>  Build output below:
> 
>  [ 98%] Building CXX object
>  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o
>  In file included from /usr/include/c++/12/ext/string_conversions.h:41,
>   from /usr/include/c++/12/bits/basic_string.h:3960,
>   from /usr/include/c++/12/string:53,
>   from
>  /export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
>   from
>  /export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
>   from
>  /export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
>  /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such
>  file or directory
> 75 | #include_next 
>    |   ^~
>  compilation terminated.
>  make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76:
>  apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
>  make[1]: *** [CMakeFiles/Makefile2:10247:
>  apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2
>  make: *** [Makefile:146: all] Error 2
> 
>  ___
>  gdal-dev mailing list
>  gdal-dev@lists.osgeo.org
>  https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 

Thanks for the docker instructions. It built nice and clean.

That still leaves the question, in my environment, why do all the apps 
except gdalsrsinfo build? I seriously doubt stdlib.h is only used by 
gdalsrsinfo.


Thanks for the help! I'll try and figure it out.

On 6/24/24 10:25, Even Rouault wrote:


Le 24/06/2024 à 19:15, Scott a écrit :
It's Debian 12. No, it's not clean. It's had several versions of gdal, 
et al, on it.


It appears srsinfo in not finding stdlib.h and all the other apps do, 
which is the part I found odd.


Docker is not the environment I'm building in.


yes, but that's the most convenient way for me to try to reproduce all 
the diverse environments people can use


Just trying the following works fine for me:

docker run --rm -it -v /home/even/gdal/3.9:/home/even/gdal/3.9 debian:12

(inside it)

cd /home/even/gdal/3.9/build_debian_12/
apt update && apt install cmake g++ make libproj-dev
cmake ..
make -j$(nproc)



Thanks!

On 6/24/24 10:01, Even Rouault wrote:

Hi,

What is the version of your Debian system ? Is it "clean" ? Can you 
for example reproduce in the corresponding debian:XXX docker image?


https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+;
 shows that this error message is quite common, although on quick reading, I 
couldn't spot a common point/solution between all those occurrences

Even

Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get the following when linking. If I 
comment srsinfo out of the makefile, all other gdal/ogr apps build 
fine with no issues.


uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux


Thanks!

Build output below:

[ 98%] Building CXX object 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o

In file included from /usr/include/c++/12/ext/string_conversions.h:41,
 from /usr/include/c++/12/bits/basic_string.h:3960,
 from /usr/include/c++/12/string:53,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
 from 
/export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such 
file or directory

   75 | #include_next 
  |   ^~
compilation terminated.
make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76: 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10247: 
apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

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



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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Even Rouault via gdal-dev 


Le 24/06/2024 à 19:15, Scott a écrit :
It's Debian 12. No, it's not clean. It's had several versions of gdal, 
et al, on it.


It appears srsinfo in not finding stdlib.h and all the other apps do, 
which is the part I found odd.


Docker is not the environment I'm building in.


yes, but that's the most convenient way for me to try to reproduce all 
the diverse environments people can use


Just trying the following works fine for me:

docker run --rm -it -v /home/even/gdal/3.9:/home/even/gdal/3.9 debian:12

(inside it)

cd /home/even/gdal/3.9/build_debian_12/
apt update && apt install cmake g++ make libproj-dev
cmake ..
make -j$(nproc)



Thanks!

On 6/24/24 10:01, Even Rouault wrote:

Hi,

What is the version of your Debian system ? Is it "clean" ? Can you 
for example reproduce in the corresponding debian:XXX docker image?


https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+; 
shows that this error message is quite common, although on quick 
reading, I couldn't spot a common point/solution between all those 
occurrences


Even

Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get the following when linking. If I 
comment srsinfo out of the makefile, all other gdal/ogr apps build 
fine with no issues.


uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux


Thanks!

Build output below:

[ 98%] Building CXX object 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o

In file included from /usr/include/c++/12/ext/string_conversions.h:41,
 from /usr/include/c++/12/bits/basic_string.h:3960,
 from /usr/include/c++/12/string:53,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
 from 
/export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such 
file or directory

   75 | #include_next 
  |   ^~
compilation terminated.
make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76: 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10247: 
apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

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



--
http://www.spatialys.com
My software is free, but my time generally not.

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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 
It's Debian 12. No, it's not clean. It's had several versions of gdal, 
et al, on it.


It appears srsinfo in not finding stdlib.h and all the other apps do, 
which is the part I found odd.


Docker is not the environment I'm building in.

Thanks!

On 6/24/24 10:01, Even Rouault wrote:

Hi,

What is the version of your Debian system ? Is it "clean" ? Can you for 
example reproduce in the corresponding debian:XXX docker image?


https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+;
 shows that this error message is quite common, although on quick reading, I 
couldn't spot a common point/solution between all those occurrences

Even

Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get the following when linking. If I 
comment srsinfo out of the makefile, all other gdal/ogr apps build 
fine with no issues.


uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux


Thanks!

Build output below:

[ 98%] Building CXX object 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o

In file included from /usr/include/c++/12/ext/string_conversions.h:41,
 from /usr/include/c++/12/bits/basic_string.h:3960,
 from /usr/include/c++/12/string:53,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
 from 
/export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file 
or directory

   75 | #include_next 
  |   ^~
compilation terminated.
make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76: 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10247: 
apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

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



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

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Even Rouault via gdal-dev 

Hi,

What is the version of your Debian system ? Is it "clean" ? Can you for 
example reproduce in the corresponding debian:XXX docker image?


https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+; 
shows that this error message is quite common, although on quick 
reading, I couldn't spot a common point/solution between all those 
occurrences


Even

Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get the following when linking. If I 
comment srsinfo out of the makefile, all other gdal/ogr apps build 
fine with no issues.


uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux


Thanks!

Build output below:

[ 98%] Building CXX object 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o

In file included from /usr/include/c++/12/ext/string_conversions.h:41,
 from /usr/include/c++/12/bits/basic_string.h:3960,
 from /usr/include/c++/12/string:53,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
 from 
/export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file 
or directory

   75 | #include_next 
  |   ^~
compilation terminated.
make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76: 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10247: 
apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

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


--
http://www.spatialys.com
My software is free, but my time generally not.

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

[gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

2024-06-24 Thread Scott via gdal-dev 
When building 3.9.1 rc1/r2 I get the following when linking. If I 
comment srsinfo out of the makefile, all other gdal/ogr apps build fine 
with no issues.


uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux


Thanks!

Build output below:

[ 98%] Building CXX object apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o
In file included from /usr/include/c++/12/ext/string_conversions.h:41,
 from /usr/include/c++/12/bits/basic_string.h:3960,
 from /usr/include/c++/12/string:53,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_error.h:256,
 from 
/export/gis/local/src/gdal-3.9.1/port/cpl_string.h:35,
 from 
/export/gis/local/src/gdal-3.9.1/apps/gdalsrsinfo.cpp:32:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file 
or directory

   75 | #include_next 
  |   ^~
compilation terminated.
make[2]: *** [apps/CMakeFiles/gdalsrsinfo.dir/build.make:76: 
apps/CMakeFiles/gdalsrsinfo.dir/gdalsrsinfo.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10247: 
apps/CMakeFiles/gdalsrsinfo.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

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

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

2024-06-24 Thread Javier Jimenez Shaw via gdal-dev 
+1 Javier

On Mon, 24 Jun 2024 at 17:09, Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> Howard
>
> On Jun 24, 2024, at 9:46 AM, Tamas Szekeres via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
> +1
>
> Tamas
>
>
> Even Rouault via gdal-dev  ezt írta (időpont:
> 2024. jún. 23., V, 0:13):
>
>> I've issued a 2nd release candidate for 3.9.1 with the following
>> additional fixes:
>> - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0
>> regression)
>>(raster/rasterio#3101)
>> - Overview generation: fix multi-threaded bug, resulting in
>> locks/crashes with
>>GeoPackage in particular (#10245)
>> - VRT: fix serialization of separatable kernel in
>> VRTKernelFilteredSource (#10253)
>> - Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to
>> avoid potential
>>undefined behavior casts
>> - OGR SQL: fix crash when the ON expression of a JOIN contains OGR special
>>fields (in particular feature id)
>> - OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
>> - OGRFeature::SetField(int, double): avoid UndefinedBehavior when
>> passing NaN
>> - OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when
>> passing value
>>close to INT64_MAX
>> - OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to
>> convert
>>NaN to Int64
>> - GeoParquet: always write version=1.1.0
>> - SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT
>> name UNIQUE (column_name)'
>>at the end of CREATE TABLE (qgis/QGIS#57823)
>> - GDALRasterBand::ComputeStatistics(): fix bad progress percentage
>> computation (3.9.1rc1 regression)
>> - OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to
>> array (3.9.1rc1 regression)
>>
>> Pick up an archive among the following ones (by ascending size):
>>
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.xz
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdal391rc2.zip
>>
>> A snapshot of the gdalautotest suite is also available:
>>
>> https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.zip
>>
>> The NEWS file is here:
>>
>> https://github.com/OSGeo/gdal/blob/v3.9.1RC2/NEWS.md
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

2024-06-24 Thread Howard Butler via gdal-dev 
+1

Howard

> On Jun 24, 2024, at 9:46 AM, Tamas Szekeres via gdal-dev 
>  wrote:
> 
> +1
> 
> Tamas
> 
> 
> Even Rouault via gdal-dev  > ezt írta (időpont: 2024. jún. 23., V, 
> 0:13):
>> I've issued a 2nd release candidate for 3.9.1 with the following 
>> additional fixes:
>> - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0 
>> regression)
>>(raster/rasterio#3101)
>> - Overview generation: fix multi-threaded bug, resulting in 
>> locks/crashes with
>>GeoPackage in particular (#10245)
>> - VRT: fix serialization of separatable kernel in 
>> VRTKernelFilteredSource (#10253)
>> - Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to 
>> avoid potential
>>undefined behavior casts
>> - OGR SQL: fix crash when the ON expression of a JOIN contains OGR special
>>fields (in particular feature id)
>> - OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
>> - OGRFeature::SetField(int, double): avoid UndefinedBehavior when 
>> passing NaN
>> - OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when 
>> passing value
>>close to INT64_MAX
>> - OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to 
>> convert
>>NaN to Int64
>> - GeoParquet: always write version=1.1.0
>> - SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT 
>> name UNIQUE (column_name)'
>>at the end of CREATE TABLE (qgis/QGIS#57823)
>> - GDALRasterBand::ComputeStatistics(): fix bad progress percentage 
>> computation (3.9.1rc1 regression)
>> - OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to 
>> array (3.9.1rc1 regression)
>> 
>> Pick up an archive among the following ones (by ascending size):
>> 
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.xz
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdal391rc2.zip
>> 
>> A snapshot of the gdalautotest suite is also available:
>> 
>> https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.zip
>> 
>> The NEWS file is here:
>> 
>> https://github.com/OSGeo/gdal/blob/v3.9.1RC2/NEWS.md
>> 
>> Even
>> 
>> -- 
>> http://www.spatialys.com 
>> My software is free, but my time generally not.
>> 
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org 
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

2024-06-24 Thread Tamas Szekeres via gdal-dev 
+1

Tamas


Even Rouault via gdal-dev  ezt írta (időpont:
2024. jún. 23., V, 0:13):

> I've issued a 2nd release candidate for 3.9.1 with the following
> additional fixes:
> - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0
> regression)
>(raster/rasterio#3101)
> - Overview generation: fix multi-threaded bug, resulting in
> locks/crashes with
>GeoPackage in particular (#10245)
> - VRT: fix serialization of separatable kernel in
> VRTKernelFilteredSource (#10253)
> - Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to
> avoid potential
>undefined behavior casts
> - OGR SQL: fix crash when the ON expression of a JOIN contains OGR special
>fields (in particular feature id)
> - OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
> - OGRFeature::SetField(int, double): avoid UndefinedBehavior when
> passing NaN
> - OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when
> passing value
>close to INT64_MAX
> - OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to
> convert
>NaN to Int64
> - GeoParquet: always write version=1.1.0
> - SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT
> name UNIQUE (column_name)'
>at the end of CREATE TABLE (qgis/QGIS#57823)
> - GDALRasterBand::ComputeStatistics(): fix bad progress percentage
> computation (3.9.1rc1 regression)
> - OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to
> array (3.9.1rc1 regression)
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.xz
>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.gz
>https://download.osgeo.org/gdal/3.9.1/gdal391rc2.zip
>
> A snapshot of the gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.tar.gz
>https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.zip
>
> The NEWS file is here:
>
> https://github.com/OSGeo/gdal/blob/v3.9.1RC2/NEWS.md
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

2024-06-24 Thread Rahkonen Jukka via gdal-dev 
+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault 
via gdal-dev
Lähetetty: maanantai 24. kesäkuuta 2024 17.07
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

Forgot to add my +1 obviously

Le 23/06/2024 à 00:13, Even Rouault via gdal-dev a écrit :
> I've issued a 2nd release candidate for 3.9.1 with the following
> additional fixes:
> - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0
> regression)
>   (raster/rasterio#3101)
> - Overview generation: fix multi-threaded bug, resulting in
> locks/crashes with
>   GeoPackage in particular (#10245)
> - VRT: fix serialization of separatable kernel in
> VRTKernelFilteredSource (#10253)
> - Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to
> avoid potential
>   undefined behavior casts
> - OGR SQL: fix crash when the ON expression of a JOIN contains OGR
> special
>   fields (in particular feature id)
> - OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
> - OGRFeature::SetField(int, double): avoid UndefinedBehavior when
> passing NaN
> - OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when
> passing value
>   close to INT64_MAX
> - OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to
> convert
>   NaN to Int64
> - GeoParquet: always write version=1.1.0
> - SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT
> name UNIQUE (column_name)'
>   at the end of CREATE TABLE (qgis/QGIS#57823)
> - GDALRasterBand::ComputeStatistics(): fix bad progress percentage
> computation (3.9.1rc1 regression)
> - OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to
> array (3.9.1rc1 regression)
>
> Pick up an archive among the following ones (by ascending size):
>
>
> https://down/
> load.osgeo.org%2Fgdal%2F3.9.1%2Fgdal-3.9.1rc2.tar.xz=05%7C02%7Cju
> kka.rahkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc9456f122
> %7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638548353038914451%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C0%7C%7C%7C=QKDKxmtYu3yqWkt%2BEJoWs2F%2FDP%2F2d
> NXNrJeqdpzJ2lY%3D=0
>
> https://down/
> load.osgeo.org%2Fgdal%2F3.9.1%2Fgdal-3.9.1rc2.tar.gz=05%7C02%7Cju
> kka.rahkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc9456f122
> %7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638548353038923721%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C0%7C%7C%7C=k%2FwOHtldnSwPj27c7KqPojnTO%2FOQwMh
> CYGHZC9HuZ5w%3D=0
>
> https://down/
> load.osgeo.org%2Fgdal%2F3.9.1%2Fgdal391rc2.zip=05%7C02%7Cjukka.ra
> hkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc9456f122%7Cc4f
> 8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638548353038929699%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C0%7C%7C%7C=206oYiEKWF2bTeYN6SsWa4fq8nBSPKWhhtPqYCzBc
> pw%3D=0
>
> A snapshot of the gdalautotest suite is also available:
>
> https://down/
> load.osgeo.org%2Fgdal%2F3.9.1%2Fgdalautotest-3.9.1rc2.tar.gz=05%7
> C02%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc
> 9456f122%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C6385483530389349
> 68%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=MPXYE%2FWq%2BwnMYK6tKCpid9b
> eoCPWFY%2BBefivpTHpjNE%3D=0
>
> https://down/
> load.osgeo.org%2Fgdal%2F3.9.1%2Fgdalautotest-3.9.1rc2.zip=05%7C02
> %7Cjukka.rahkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc945
> 6f122%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638548353038939284%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=o6qmt5kC1FbwhjGdIlH3cnlQRezBKO
> KoW80sjdtvxcY%3D=0
>
> The NEWS file is here:
>
>
> https://gith/
> ub.com%2FOSGeo%2Fgdal%2Fblob%2Fv3.9.1RC2%2FNEWS.md=05%7C02%7Cjukk
> a.rahkonen%40maanmittauslaitos.fi%7C8a878635699b4327b7a808dc9456f122%7
> Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638548353038943612%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C0%7C%7C%7C=bO%2ByyJi9Pbq%2BV9i09xFtnn8hG6iJQbzmZ
> UMW%2Bfwo%2FC0%3D=0
>
> Even
>
--
http://www.spatialys.com/
My software is free, but my time generally not.

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

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

2024-06-24 Thread Even Rouault via gdal-dev 

Forgot to add my +1 obviously

Le 23/06/2024 à 00:13, Even Rouault via gdal-dev a écrit :
I've issued a 2nd release candidate for 3.9.1 with the following 
additional fixes:
- GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0 
regression)

  (raster/rasterio#3101)
- Overview generation: fix multi-threaded bug, resulting in 
locks/crashes with

  GeoPackage in particular (#10245)
- VRT: fix serialization of separatable kernel in 
VRTKernelFilteredSource (#10253)
- Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to 
avoid potential

  undefined behavior casts
- OGR SQL: fix crash when the ON expression of a JOIN contains OGR 
special

  fields (in particular feature id)
- OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
- OGRFeature::SetField(int, double): avoid UndefinedBehavior when 
passing NaN
- OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when 
passing value

  close to INT64_MAX
- OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to 
convert

  NaN to Int64
- GeoParquet: always write version=1.1.0
- SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT 
name UNIQUE (column_name)'

  at the end of CREATE TABLE (qgis/QGIS#57823)
- GDALRasterBand::ComputeStatistics(): fix bad progress percentage 
computation (3.9.1rc1 regression)
- OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to 
array (3.9.1rc1 regression)


Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.xz
  https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.gz
  https://download.osgeo.org/gdal/3.9.1/gdal391rc2.zip

A snapshot of the gdalautotest suite is also available:

https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.tar.gz
  https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.zip

The NEWS file is here:

   https://github.com/OSGeo/gdal/blob/v3.9.1RC2/NEWS.md

Even


--
http://www.spatialys.com
My software is free, but my time generally not.

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