Re: [gdal-dev] GDAL mailing list email delays

Markus Neteler via gdal-dev writes: > Am 29.05.25 um 7:55 PM schrieb Greg Troxel via gdal-dev: >> The way to debug this is to look at the logs at the computer that >> receives your mail from lists.osgeo.org, and to see if it is >> implementing greylisting. > > Yes,

Re: [gdal-dev] GDAL mailing list email delays

Barry DeZonia via gdal-dev writes: > For the record it is not just this user experiencing issues. I > received the java bindings Original email 11 minutes after the Reply > to that email.came through. However, I am accessing mail via gmail.com > too. Please open a support ticket to have the logs

Re: [gdal-dev] GDAL mailing list email delays

Daniel Evans via gdal-dev writes: > Tom's initial email was delayed by 48 minutes, arriving at 1715 UTC: > - Originally sent by the mailing list at 1627 UTC > - After a few internal hops, received by lists.osgeo.org at 1636 UTC (with > a header stating X-Greylist: delayed by 473 seconds) > - Rece

[gdal-dev] float16 woes on solaris

The pkgsrc package isn't building on SmartOS (which is illumos, which is OpenSolaris, more or less). Full build at the last link: https://reports.pkgci.org/SmartOS/upstream/trunk/20250518.2249/meta/report.html https://reports.pkgci.org/SmartOS/upstream/trunk/20250518.2249/gdal-lib-3.11.0/co

Re: [gdal-dev] float16 woes on solaris

The build I posted was gcc 13. This might be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.11.0 release candidate available

Sebastiaan Couwenberg via gdal-dev writes: > This seems to have caused breakage on some architectures where -latomic is > needed explicitly, as it now fails to build on armel & powerpc: > > > https://buildd.debian.org/status/fetch.php?pkg=gdal&arch=armel&ver=3.11.0%7Erc1%2Bdfsg-1%7Eexp1&stamp=

Re: [gdal-dev] How can I avoid absolute path to shared libraries in libgdal.so

"Fox, Shawn D (US) via gdal-dev" writes: > I'm sure a lot of people have opinions > about the concept of rpath vs using LD_LIBRARY_PATH. I'm not > interested in discussing that. Our team does have a complicated > application build and distribution process, and it isn't useful to try > and expla

Re: [gdal-dev] How can I avoid absolute path to shared libraries in libgdal.so

"Fox, Shawn D (US) via gdal-dev" writes: > ldd libgdal.so > linux-vdso.so.1 (0x7ffe0e3f7000) > libdl.so.2 => /lib64/libdl.so.2 (0x7feaca6a6000) > libcurl.so.4 => /lib64/libcurl.so.4 (0x7feaca417000) > libproj.so.22 => not found > libexpat.so.1 =

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault writes: > those errors are related to the new float16 (RFC100) support. Support > for that type is a bit weak with some compilers / C/C++ libraries. Can > you give a try at https://github.com/OSGeo/gdal/pull/12165 ? Thanks for the quick fix! With that patch, I get a successful buil

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault writes: > No, std::abs() is fine there. Fixed per > https://github.com/OSGeo/gdal/commit/2d169a75c24aece05be9bba588d50bc055e9b9ac great, thanks. > Those ones are related to the use of the old PCRE library. Should be > fixed per > https://github.com/OSGeo/gdal/commit/0e38a13e0c7784d

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault via gdal-dev writes: > https://github.com/OSGeo/gdal/blob/v3.11.0beta1/NEWS.md I'm seeing errors on two or three files about what I think is referring to std::isinf and std::isnan with just isinf and isnan. Adding std:: before isinf/isnan seems to make it build. And, I see existin

Re: [gdal-dev] GDAL release compatibility with external libraries

"Fox, Shawn D (US) via gdal-dev" writes: > I recently read the details of RFC 98: Build requirements for GDAL 3.9 > - GDAL > documentation, > and I was wondering if there is any similar info for previous versions >

Re: [gdal-dev] Motion: adopt GDAL 3.10.2RC1 as final 3.10.2 release

I think 24h is way too fast for people to be able to test, so I would be -1 if I had a 1 to throw around, which I don't. (3.10.2RC1 did build for me on NetBSD 10/amd64 and with it qgis opens my layers just fine.) ___ gdal-dev mailing list gdal-dev@lists.

Re: [gdal-dev] GDAL 3.10.2 release candidate available

Even Rouault via gdal-dev writes: > The main trigger for it is the recent Poppler 25.02.00 release that > breaks their C++ unstable API and require code changes on our side. So > rather than letting each package maintainer cherry-picks the > appropriate patch commit, let's issue a clean release.

Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

Even Rouault via gdal-dev writes: > - less provocative: add telemetry. obviously not opt-in because nobody > would take the time to turn it on, but just opt-out I know you said don't blow a gasket on your suggestions, but this is really not an ok thing to do. In all seriousness, I think the

Re: [gdal-dev] UTM local correction for height and distance-to-reference-meridian ?

Peter Bennewitz via gdal-dev writes: > To get exact distances between local points, UTM requires a correction > factor, depending on local height and distance to the UTM reference > meridian. Mainly due to UTM's 6deg steps, - as opposed to the smaller > 3deg of GK, where this correction could hav

Re: [gdal-dev] Improving GDAL production in our release

David Klaus writes: > Thank you for your fast response. > > Q: You didn't explain whether you are doing import/merge and carrying diffs > to the sources, and if so, you didn't give a link where others can look at > them. > > A: I apologize if I misunderstand your questions. I think you are asking

Re: [gdal-dev] Improving GDAL production in our release

David Klaus via gdal-dev writes: > I am reaching out for advice on streamlining the process my company uses to > produce new versions of GDAL for our releases. Currently, we maintain a > batch file that handles some preliminary setup tasks and then initiates a > custom GDAL build using CMake. Unf

Re: [gdal-dev] LIBERTIFF / Thread-safe TIFF reader

Even Rouault via gdal-dev writes: > Now for the PROJ community only: my evil idea when coding it was that > I could ""port"" a very subset of it to remove the libtiff depedency > from PROJ. As we only uses Deflate compression, at least for grids we > host on proj-data / the CDN, we could just swi

Re: [gdal-dev] GPU support for GDAL

Pradeep Mahato via gdal-dev writes: > In second approach i am facing issue in stacking and making it as one > ".ovr" file. So Pls help me in this regard. If you are going to ask for help, you should have your goals and software design in writing, and publish them. Before doing that, you should

Re: [gdal-dev] Github, AI and the proposed RFC 8 amendment

Andrew C Aitchison via gdal-dev writes: > Agreed. > > However, as I understand it, by using github we have allowed > copilot to include our code without it being covered by the usual > licence. Perhaps "acquiesced", but the project does not have to right to grant hat license for code whose copyr

Re: [gdal-dev] Proposed RFC 8 amendment regarding (prohibited use of) generative AI tools

ElPaso via gdal-dev writes: > I have read the discussion on lwn and I must say that I am more in > line with the debian position. My view is that code that comes out of generative AI should be viewed as an improper derived work, and lacking adequate provenance/permission to be added to an open s

Re: [gdal-dev] [PROJ] RFC 102: Embedding resource files into libgdal (and PROJ)

Even Rouault via PROJ writes: > Sending to both gdal-dev and proj, as this is intended to be a joint RFC. > > Summary: This RFC uses C23 ``#embed`` pre-processor directive, when > available, to be able to embed GDAL resource files directly into > libgdal. It is also intended to be used for PROJ,

Re: [gdal-dev] Assistance Required for Downloading GDAL Libraries and Dependencies for aarch64 and Static Compilation on LS1046 ARM64 Processor

Cross compilation requires a destdir for the target architecture, already populated with ilbs and includes. It looks to me like your cross environment is not set up correctly - and that's in my view out of scope for gdal-dev. I would suggest that you first be able to cross compile a number of pro

Re: [gdal-dev] Is there a FACE Conformant version of GDAL and its DTED drivers?

Ethan Payne via gdal-dev writes: > I'm currently assisting with a project that involves using DTED files > to analyze terrain and elevation. As this project adheres to the FACE > Technical Standard and must meet FACE Conformance requirements, I > wanted to inquire whether there is a version of GD

Re: [gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

Even Rouault via gdal-dev writes: > 3) You would get the most precise result (with lots of quotes, > because this is highly subjective, and assumes that NAD83(HARN) is > equivalent to WGS 84, according to the comment in the EPSG database) > with the "NAD27 to WGS 84 (41)" EPSG transformat

Re: [gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

"Fox, Shawn D (US) via gdal-dev" writes: > I have noticed that from GDAL 1.10 - GDAL 3.1.0 that gdaltransform is > producing different results for NAD27 GCS to WGS84 GCS > transformations. The differences in longitude in the output is more > significant. Having tested the differences in feet be

Re: [gdal-dev] GDAL 3.9.2 release candidate available

Even Rouault via gdal-dev writes: >   https://download.osgeo.org/gdal/3.9.2/gdal-3.9.2rc1.tar.xz On NetBDS 10 amd64, I locally updated pkgsrc, and gdal-lib, py-gdal (bindings split package), and qgis all built without issues, and the resulting qgis, when run on a project with a lot of layers of

Re: [gdal-dev] shapelib 1.6.1RC2 available (was Re: shapelib 1.6.1RC1 available)

Even Rouault via gdal-dev writes: > Here's a shapelib v1.6.1 RC2: > - https://download.osgeo.org/shapelib/shapelib-1.6.1rc2.tar.gz > - https://download.osgeo.org/shapelib/shapelib-1.6.1rc2.zip > > Changes since v1.6.1RC1: > - shapefil.h: bump version number to 1.6.1 > - CMake: (>= 3.21) Fix ctest

Re: [gdal-dev] shapelib 1.6.1RC2 available (was Re: shapelib 1.6.1RC1 available)

(I'm building with autoconf.) 1) It builds fine on NetBSD 10 amd64, using an old pkgsrc workaround/?? to explicitly build only the libs (that may well be no longer relevant): # \todo Explain why we don't install what shapelib installs. # \todo Perhaps file a bug upstream that the bin programs

Re: [gdal-dev] dealing with complex (a+ib) images

Javier Jimenez Shaw via gdal-dev writes: > I have to create a complex number (real and imaginary part) image out of > two "normal" images or bands. > How can I do it? I don't know, but it would be great if you explained what that means. I did a quick web search and didn't find anything. There i

Re: [gdal-dev] Building GDAL documentation with ReadTheDocs

Daniel Baston via gdal-dev writes: > Hello, > > I've put together a configuration to build GDAL's documentation using > ReadTheDocs. As far as I know, this is the simplest way of publishing > version-specific documentation and rending documentation for pull > requests. A current build of the docu

Re: [gdal-dev] GDAL 3.7.0 Proj 6.3.1 strange behavior when performing NAD83(EPSG:4152) to NAD83 HARN(EPSG:4269) realization transformation

David Klaus writes: > Thank you for the input. You don't happen to know where I can find > documentation on these NADCON5 related changes? I would suggest reading the 9.2.0 release notes. There is a link to a merged PR which has further discussion. The tl;dr; is that proj matches NGS tools. Wh

Re: [gdal-dev] GDAL 3.7.0 Proj 6.3.1 strange behavior when performing NAD83(EPSG:4152) to NAD83 HARN(EPSG:4269) realization transformation

David Klaus writes: > As far as upgrading Proj4; because we build Proj4 statically in our custom > build, it's not a trivial task to upgrade versions. Also, I think there > might be compatibility reasons why we've stuck with 6.3.1 up until now. > > But if NAD83 realization transformation function

Re: [gdal-dev] GDAL 3.7.0 Proj 6.3.1 strange behavior when performing NAD83(EPSG:4152) to NAD83 HARN(EPSG:4269) realization transformation

You didn't, as far as I can tell, post the code that is not doing what you want. Or perhaps turn that code into a small test case program. People reading that would be able to be more helpful, and the code example could help others. Proj 6.3 is quite old. I recommend you update to the latest re

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

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

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

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

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

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.

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

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 exp

Re: [gdal-dev] GDAL 3.9.1 release candidate available

Even Rouault via gdal-dev writes: >   https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc1.tar.xz I locally updated pkgsrc, and it builds fine on NetBSD 10 amd64. qgis 3.36 using it (without recompiling qgis) starts up and loads geopackage vector layers and postgis vector layers. So seems good

Re: [gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

Even Rouault via gdal-dev writes: > Motion: > > Adopt GDAL 3.9.1RC1 as 3.9.1 release I haven't had a chance to test in the 24h59m between the rc and proposing a release. Not sure when I will, but this interval seems super short. Of the beyond-core-team people that usually test, has anybody el

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

Even Rouault writes: > [cmake] Thanks for cluing me in; that all makes sense. > No idea if you need gcc 7 or 8. I don't think we use super advanced > C++17 features, so gcc 7 might be fine, but only experimentation would > confirm that. I believe the minimum we test on our CI is gcc 9.4 that >

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 - fail the build if that does not work with a message that makes it clear that the compiler doesn't work --std=c++17 - if it works, add --std=c++17 to

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

Even Rouault writes: >> which is misplaced, because people are who merely intending to compile >> gdal but not contribute to it, still need to know. I almost didn't even >> look at it before writing that it wasn't documented which C++ flavor is >> needed, because it was obviously not about what

[gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

1) README.md points to build hints (my fault if that's wrong..): https://gdal.org/development/building_from_source.html but really there is crucial information (like that a C++ compiler is required!) at https://gdal.org/development/dev_environment.html which is misplaced, because people are

Re: [gdal-dev] building just the python bindings (cmake)

I got 3.5 to work, so I'm focusing on the 3.9 upgrade. It seems that 3.9, vs 3.5, has withdrawn the swig generated files from the distfile. With 3.9, you could also do a more manual approach (not sure the python_generated_files target is available in 3.5) cmake .. make GDAL  # build the

Re: [gdal-dev] building just the python bindings (cmake)

Even Rouault writes: > If the build requirements for the Python bindings are met (python + > swig available), then a "make && make install" cycle will build and > install libgdal and the python bindings, like it did in autoconf > era. The CMake build target "python_binding" has libgdal as a > dep

[gdal-dev] building just the python bindings (cmake)

I had not gotten to converting the pkgsrc package to cmake, because it seemed like it would take a long time. So gdal is at 3.5.3, the last one that works with autoconf. Yes, I know that 3.5 was about two years ago. It turns out that it is taking hours to do the conversion, and the good news is

Re: [gdal-dev] false easting and northing units

Kirk Waters - NOAA Federal via gdal-dev writes: > Thanks for the explanation and tips. I'm not clear on how setting to 26988 > (Michigan North meters) would help. If I do a gdal_translate with that, it > shows as being in New Zealand, just as Arc had done. It would certainly > make lots more sens

Re: [gdal-dev] Un-vendoring a number of third-party libraries?

Even Rouault via gdal-dev writes: > I'm considering removing from the source tree a number of third-party > libraries that we have vendored over the years: zlib, libpng, libjpeg, > giflib, liblerc I'm basically strongly in favor of un-vendoring. I view vendoring as a bug, even if it is a workar

Re: [gdal-dev] Requiring numpy for the Python bindings

Laurențiu Nicola via gdal-dev writes: > On Wed, Dec 6, 2023, at 16:23, Greg Troxel via gdal-dev wrote: >> Keeping rust going has been an ongoing source of work and problems. >> This is partly because of not having a reasonable bootstrap story from >> C/C++, and mostly

Re: [gdal-dev] Requiring numpy for the Python bindings

Laurențiu Nicola via gdal-dev writes: > 1. do the platforms you care about package Firefox, librsvg, or any > other popular software that's using Rust? pkgsrc supports multiple operating system, multiple versions of those systems, and multiple cpu architectures. There are probably over a hundre

Re: [gdal-dev] Requiring numpy for the Python bindings

Thomas Knudsen writes: > Den tirs. 5. dec. 2023 kl. 02.15 skrev Greg Troxel via gdal-dev < > gdal-dev@lists.osgeo.org>: >> Building the >> rust compiler requires the *immediately preceding* compiler, which seems >> unprecented, and I don't understand how peo

Re: [gdal-dev] Requiring numpy for the Python bindings

Even Rouault via gdal-dev writes: > The current situation where numpy is an optional dependency of the > GDAL Python bindings is quite cumbersome to deal with our setup.py's > setuptools . All details (a bit tricky) in > https://github.com/OSGeo/gdal/issues/8069 . It seems it would be > simpler i

Re: [gdal-dev] How do GCP's in a VRT file work?

Joe Lovick via gdal-dev writes: >        What is the recommended processing paradigm for slightly > off-nadir imagery where their is a need for a full [3x3] matrix > mapping to take it to a consistent projection? ie the images have at a > minimum perspective effects. > >     the reason i ask, is

Re: [gdal-dev] How do GCP's in a VRT file work?

Joe Lovick via gdal-dev writes: > Could someone explain how GCP's placed into a VRT file work, i was > expecting a linear/bi-linear, or polynomial fit between the points for > the simplest EPSG:4326 projection.however that is not what i see, > adjusting a single point, effects the projection of a

Re: [gdal-dev] including higher-level library in GPX creator string

Even Rouault via gdal-dev writes: > Cf https://github.com/OSGeo/gdal/pull/8558: "GPX: add a CREATOR > dataset creation option" Thanks; long pause on my part to let this settle in my head. > It will be of course up to the application / application user to set it. I guess the really interesting

[gdal-dev] including higher-level library in GPX creator string

I am a member of the GPX standards list, and we are discussing a new version and also dealing with broken data. I wrote a gpx (from geojson), with just ogr2ogr, and the creator looks like this: creator="GDAL 3.5.3" that's arguably totally fine with ogr2ogr. But it seems that if some random bi

Re: [gdal-dev] Call for discussion/review of RFC95: Use standard C/C++ integer types

Sean Gillies writes: > I'm in favor of overhauling the types in the next major version. However, > I'm not convinced we need to jump immediately to 4.0. The current situation > isn't ideal, but isn't holding us back very much right? GDAL is growing new > features rapidly and it doesn't seem that

Re: [gdal-dev] Folder shared with you: "GDal Community"

"Vijay Kurhade (via Google Drive)" writes: > I've shared an item with you: > > GDal Community > https://drive.google.com/drive/folders/1xylPKQy0uJM3zbcqyxdvdSnxCaFh8lox?usp=sharing&invite=COKSqLgO&ts=649b10f2 > > It's not an attachment -- it's stored online. To open this item, just > click the li

Re: [gdal-dev] Improving details of the project build system and/or documentation

Even Rouault writes: some thoughts on the thoughts from a packaging viewpoint. > - you definitely don't want to build all drivers (that can be built as > plugins) as plugins. This works (this is actually my dev setup, to > ensure that the core exports all the symbols needed for drivers > b

Re: [gdal-dev] Improving details of the project build system and/or documentation

Brad Hards writes: > On Monday, 29 May 2023 8:20:32 AM AEST Sean Gillies wrote: >> I resented being told on this list (not by you, Even) that I could >> take it or leave it with regards to the current build situation. > > I assume this is directed at me (since I don't see anyone else on the thre

Re: [gdal-dev] question about python installation

Michael Sumner writes: > I've been trying with PYTHONPATH and sys.path, and I think I was doing it > wrong ... but the simplicity of the /usr prefix had not occurred to me, > I'll be doing that. > > If I come back around with further insights I'll share them, but this is > working for me now. >

Re: [gdal-dev] building against external tiff/geotiff sources ?

Sebastiaan Couwenberg writes: > On 3/4/23 11:10, Landry Breuil wrote: >> what do other packagers of gdal think about it ? Providing an >> option/flavor for end-users of the packaging system to build against >> internal copies might also be possible, but that creates havoc in >> dependency trees..

Re: [gdal-dev] Advanced 3.6.1 release and retraction of 3.6.0 ?

Even Rouault writes: > Question: now that 3.6.1 is out, what to do with the > osgeo/gdal:-3.6.0 docker images: > > - keep them > > - remove them > > - alias them to the 3.6.1 ones which are now available ? Basically I'm with Bas on this. But even more strongly, do not alias 3.6.0 to 3.6.1.

Re: [gdal-dev] Motion: adopt GDAL 3.5.3RC1 as final 3.5.3 release

Even Rouault writes: > I indeed see that some generated files have a lower timestamp than > their .i sources. Probably something due to some files being > regenerated as identical (apart higher timestamp) to their existing > versions in git and thus not being committed into git. There is > nothi

Re: [gdal-dev] Motion: adopt GDAL 3.5.3RC1 as final 3.5.3 release

the problem is that work/gdal-3.5.3/swig/python/extensions/gnm_wrap.cpp has the same timestamp (in the tar file) as work/gdal-3.5.3/swig/include/gnm.i running touch work/gdal-3.5.3/swig/python/extensions/gnm_wrap.cpp after unpack and before build results in a successful build. I guess

Re: [gdal-dev] Motion: adopt GDAL 3.5.3RC1 as final 3.5.3 release

Greg Troxel writes: > I wasn't able to test this promptly, but am doing that now on netbsd-9 > amd64 with python 3.10. And I am still using the autoconf build. > gdal-lib (no python) built fine > > py-gdal (python bindings) is failing with what smells like a GNUism in >

Re: [gdal-dev] Motion: adopt GDAL 3.5.3RC1 as final 3.5.3 release

I wasn't able to test this promptly, but am doing that now on netbsd-9 amd64 with python 3.10. gdal-lib (no python) built fine py-gdal (python bindings) is failing with what smells like a GNUism in sed patterns, but it's possible this is a change in pkgsrc not gdal and I haven't figured it out.

Re: [gdal-dev] Transformations with same horizontal datum but different geoid outputs the same Z value

Andrew C Aitchison writes: > On Mon, 17 Oct 2022, Diogo wrote: > >> Hi Andrew. Thanks for taking the time to read my email and reply it. >> I'm aware of Copernicus land and other datasets like SMRT3 and ASTER >> however I need the best possible elevation resolution available. To do so, >> I'm ge

Re: [gdal-dev] autoconf and nmake build systems ready to be removed

Even Rouault writes: >> I use cmake on master, but have not converted the package yet. > You've still time as this will reach a release for 3.6.0 in > November. This email is mostly for people having CI or other similar > nightly build processes that track GDAL master. What I do, usually only w

Re: [gdal-dev] autoconf and nmake build systems ready to be removed

Even Rouault writes: > Hi, > > Great news: the final step of the CMake migration (checklist in > https://github.com/OSGeo/gdal/issues/5680), the removal of the > autoconf and nmake build systems > (https://github.com/OSGeo/gdal/pull/6110) is now ready to be merged. > > Are there people who track

Re: [gdal-dev] Build GDAL 3.5 for iOS error: forward declaration of 'stat64'

Even Rouault writes: > That's what we do already what we do for a few functions (like fopen64 > vs fopen): cf > https://github.com/OSGeo/gdal/blob/1e3cc18e298e81c1f42162b10ef7beb0dd94d3cf/cmake/helpers/configure.cmake#L230 > > But for some reason, in that circumstance, it seems it detects symbol

Re: [gdal-dev] Build GDAL 3.5 for iOS error: forward declaration of 'stat64'

Even Rouault writes: > Can you try the following patch which basically forces to remap all > "foo64" functions to "foo". I assume that iOS Unix I/O is 64-bit > enabled by default... I would expect it is. The BSD world changed the ttype of size_t, off_t to 64 bits a really long time ago and in

Re: [gdal-dev] CMAKE_INSTALL_PREFIX gdalinfo still looks for .dylib in /usr/lib

Even Rouault writes: > Le 04/07/2022 à 07:32, Brad Hards a écrit : >> On Monday, 4 July 2022 3:19:55 PM AEST Nik Sands wrote: >>> Is it expected that these GDAL utilities (such as gdalinfo) would look for >>> GDAL in /usr/lib instead of the location in which it was actually built? >> No. >> >> I

Re: [gdal-dev] GDAL 3.5.1 RC1 available

Even Rouault writes: > https://download.osgeo.org/gdal/3.5.1/gdal-3.5.1rc1.tar.xz This built within pkgsrc, with no changes to the set of installed files (our PLIST file), and just a micro shlib bump. Note that I am still building pkgsrc with autoconf. autotest seems as ok as it's been on my

Re: [gdal-dev] building on macOS - fatal error: 'direct.h' file not found

Nik Sands writes: > Since I last built GDAL (2.2.2), cmake has been introduced and it > appears as though it is going to be the only option going forward. So > I’m attempting to use cmake to build GDAL 3.5.0 on macOS 12.4 > ('Monterey’). I’ve installed cmake using the ‘homebrew’ macOS package

Re: [gdal-dev] building python bindings after cmake compilation

Saulteau Don writes: > I have gdal 3.5.0 built using the new cmake system. > /chroot/src/build <- cmake build directory > /chroot/src/gdal <- src directory > /chroot/src/gdal/swig/python > > My cmake is ran from the /chroot directory: > >> cmake -B build -S gdal \ >> -DCMAKE_BUILD_TYPE='No

Re: [gdal-dev] Building with cmake

Greg Troxel writes: > The problem is that there are no instructions for building with cmake, > and something that normally works with cmake does not. By 'there are no > instructions', I mean that I looked at README.md (which is hard to read > in text because of all the

Re: [gdal-dev] GDAL 3.5.0 release candidate available

Even Rouault writes: > https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc1.tar.xz All on NetBSD 9 amd64. I built this in pkgsrc, using autoconf (because that's how the package is from 3.4.x). It built fine, with minor changes in installed files. (In addition to what's in NEWS, include/gdalcac

Re: [gdal-dev] Building with cmake

Even Rouault writes: > In-tree CMake builds are only partly supported currently, because of > the continued support of autoconf/nmake and conflicts between > generated files of CMake with files used by autoconf/nmake. We should > be able to fix that once support for autoconf/nmake is gone > > An

Re: [gdal-dev] Building with cmake

Paul Harwood writes: > I get that error message when I try to use the source directory as the > build directory. > > With cmake, it is better to use a different folder structure for the build > - if I remember correctly something like running cmake in a clean version > of the repository but usin

Re: [gdal-dev] GDAL 3.4.3 RC1 available

Even Rouault writes: > https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.xz On NetBSD 9 amd64 with all prereqs from pkgsrc: - locally updated pkgsrc to the above tarball as if released - built and installed the base lib and the python packages. - updated gdal git to release/3.4 a

Re: [gdal-dev] gdal with stack smash protection

Kavitha K writes: > I m looking for gdal with build support - stack smash protection > > please confirm whether it is supported with stack smash protection > > if yes, which version is supported? This is the dev list, so I'm assuming - you are already comfortable building gdal - you have a

Re: [gdal-dev] zlib vulnerability CVE-2018-25032 affecting GAL

Even Rouault writes: > Most GDAL binary distributions don't use that internal copy but the > external zlib library provided by the operating system / distribution > channel. I realize you are accomodating people who can somehow get and build gdal sources but can't first install zlib, but from t

Re: [gdal-dev] Memory allocation issues on Android 11+ and scudo

Philippe Lelong writes: > My typical test is using Netherlands S57 charts > (https://vaarweginformatie.nl/frp/main/#/page/infra_enc, take zeeland > and nederland at the end of the page), and open/close them one by one > in a loop. > > > I have not tried "release_to_os_interval_ms", I will. Even

Re: [gdal-dev] The Not Rocket Science Rule Of Software Engineering

Andrew C Aitchison writes: > I have been reading The Not Rocket Science Rule Of Software Engineering > https://graydon2.dreamwidth.org/1597.html > which is: >automatically maintain a repository of code >that always passes all the tests > > Does https://github.com/OSGeo/gdal have

Re: [gdal-dev] Memory allocation issues on Android 11+ and scudo

Philippe Lelong writes: > What I can see is that the memory grows exponentially until no more > memory is available and crash, even on systems with huge memory > available while an Android device without SCUDO and very limited > memory (let's say 4Gb) in the same exact conditions, with the same

[gdal-dev] CI status - passing on all platforms?

background: I am testing the cmake build and then will be converting the pkgsrc package to use cmake so I can be ready for 3.5.0. Because I am not aware of any pre-release distribution tarballs with up-to-date cmake support, I'm heading down the path of what would be "make dist" in aut

Re: [gdal-dev] GDAL, Proj and cacert

Howard Butler writes: >> On Feb 11, 2022, at 1:41 PM, Jeff McKenna >> wrote: >> >> Unfortunately this issue comes up very often, as you said, so much >> of our stack relies heavily on environment variables. My hope is >> that in the long run, the ini-style of settings can help battle this >>

[gdal-dev] cmake status update - 99% good news!

I have started testing cmake support on gdal master. My approach is 1) Build gdal from git using cmake. 2) Be able to create a release tarball (not actually a release of course) from master in order to use for building with pkgsrc. 3) Build the release using autoconf, basically unchange

Re: [gdal-dev] Shortening schedule for CMake adoption ?

Even Rouault writes: > Greg, > > I will not respond point by point, but the message here is: "CMake > support is available and believed to be in good shape into master > based on our manual tests and initial CI configuration exercising it, > it will replace autotools+nmake soon, be ready for it

Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

If that is meant to apply mainly to drivers with proprietary SDKs, it looks fine. It's a little hard to tell which things apply to drivers that don't have proprietary dependencies. For example: Drivers require a designated responsible contact. seems perhaps a bit much, perhaps not, for some

Re: [gdal-dev] Shortening schedule for CMake adoption ?

Even Rouault writes: > The new CMake build system > (https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent > progress, and I believe that it should be in a production ready state > on time for GDAL 3.5.0 (~ May). It is already very close to it > according to a checklist I had cre

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > That git tree reorganization alone should hardly impact packagers > still using autoconf, as the release tarball structure will be > unchanged. This only impacts folks building from git > > The full cmake transition will certainly require more time, but that > will probabl

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > ==> I've thus gone to "git mv gdal/* ." to remove the gdal/ > subdirectory. Of course number of boring changes were needed to adapt > CI scripts, Docker, mkgdaldist.sh, etc.  This will also impact > downstream users building from git once that work will have landed > into

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > For most packaging system, the set of dependencies available at build > time is fully controlled by the package requirements. We can assume > that whatever if available is wished to be used, and ideally a plain > "cmake .." should automatically find what is available. And

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Javier Jimenez Shaw writes: > How would CMake behave with all those options that are defined depending on > what is present on the compiler machine? > > IMHO, the libraries included should be independent on what is already > installed on the compiler machine. The last time something/somebody > i

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that proposes: > > - to develop a CMake build system, officially integrated in the source tree. > > - and remove the current GNU makefiles and nmake build systems, when > the CMake build system has matured enough

Re: [gdal-dev] test failures on pkgsrc build of 3.3.2rc3

Even Rouault writes: >> FAILED gdrivers/eedai.py::test_eedai_GOOGLE_APPLICATION_CREDENTIALS - assert >> ... > Not sure what happens here. Probably some harden configuration of > openssl that rejects the private key ? Apparently it fails on Mac too > from > https://github.com/OSGeo/gdal/commit/7

  1   2   >