[gdal-dev] QGIS - was Re: GDAL 3.12.2 release candidate

[Andrew C Aitchison]

On Thu, 5 Feb 2026, Greg Troxel via gdal-dev wrote:

> Andrew C Aitchison via gdal-dev <gdal-dev at lists.osgeo.org> writes:
>
>> On Wed, 4 Feb 2026, Greg Troxel via gdal-dev wrote:
>>
>>> Builds warning free on NetBSD 10 amd64 and aarch64 (gcc10).
>>> With it installed, qgis works on amd64.
>>
>> Is that a custom-built qgis, or can the system qgis use
>> the new gdal libraries ?
>
> NetBSD's base system includes only things that are traditionally part of
> UNIX, or would be today (cat, cc, and so on).  So there is no such thing
> as "system qgis".  pkgsrc is used to build the vast amount of software
> beyond the base, and that includes qgis, gdal, etc.  I have qgis as
> /usr/pkg/bin/qgis, and that links to a bunch of libraries, the
> non-base-UNIXy of which are in /usr/pkg/lib.
>
>  # Full output 223 lines - much snipped.
>  $ ldd /usr/pkg/bin/qgis
>  /usr/pkg/bin/qgis:
>          -lexecinfo.0 => /usr/lib/libexecinfo.so.0
>          -lelf.2 => /usr/lib/libelf.so.2
>          -lc.12 => /usr/lib/libc.so.12
>          -lgcc_s.1 => /usr/lib/libgcc_s.so.1
>          -lqgis_app.3.44.7 => /usr/pkg/lib/libqgis_app.so.3.44.7
>          -lqwt.6.3 => /usr/pkg/qwt-6.3.0/lib/libqwt.so.6.3
>          -lQt5PrintSupport.5 => /usr/pkg/qt5/lib/libQt5PrintSupport.so.5
>          -lQt5Widgets.5 => /usr/pkg/qt5/lib/libQt5Widgets.so.5
>          -lQt5Gui.5 => /usr/pkg/qt5/lib/libQt5Gui.so.5
>          -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5
>          -lz.1 => /usr/lib/libz.so.1
>          -ldouble-conversion.3 => /usr/pkg/lib/libdouble-conversion.so.3
>          -lstdc++.9 => /usr/lib/libstdc++.so.9
>          -lm.0 => /usr/lib/libm.so.0
>          -licui18n.78 => /usr/pkg/lib/libicui18n.so.78
>          -licuuc.78 => /usr/pkg/lib/libicuuc.so.78
>          ...
>          -lgdal.38 => /usr/pkg/lib/libgdal.so.38
>          -larchive.5 => /usr/lib/libarchive.so.5
>          -llzma.2 => /usr/lib/liblzma.so.2
>          -lxml2.16 => /usr/pkg/lib/libxml2.so.16
>          -lqhull_r.8.0 => /usr/pkg/lib/libqhull_r.so.8.0
>          -lxerces-c-3.3 => /usr/pkg/lib/libxerces-c-3.3.so
>          -ljpeg.8 => /usr/pkg/lib/libjpeg.so.8
>          -ltiff.6 => /usr/pkg/lib/libtiff.so.6
>          ...
>          -lpython3.13.1.0 => /usr/pkg/lib/libpython3.13.so.1.0
>          -lutil.7 => /usr/lib/libutil.so.7
>
> When viewed from the perspective of GNU/Linux distributions which have
> (from the traditonal UNIX perspective) merged base/packages in /usr,
> /usr/pkg/bin/qgis is "system" qgis in that it was installed by the
> packaging system rather than built by the user.
>
> I am the package maintainer for qgis and gdal (and others), so what I do
> is update the packaging entry for gdal from 3.12.1 (which is what the
> rest of the world sees) to 3.12.2rc1 and rebuild the package and then
> update the system with that package.   So on my computer I have:
>
>  $ ls -l /usr/pkg/lib/libgdal.so*
>  lrwxr-xr-x  1 root  wheel        13 Feb  3 13:37 /usr/pkg/lib/libgdal.so -> libgdal.so.38
>  lrwxr-xr-x  1 root  wheel        20 Feb  3 13:37 /usr/pkg/lib/libgdal.so.38 -> libgdal.so.38.3.12.2
>  -rwxr-xr-x  1 root  wheel  29683336 Feb  3 13:37 /usr/pkg/lib/libgdal.so.38.3.12.2
>
> qgis thus uses that when it starts because it was linked against
> libgdal.so.38 and that resolves.  Because there was no API/ABI change in
> a micro, I don't need to rebuild it.  If I do need to rebuild qgis,
> because of API/ABI changes, I'd "make replace" in
> /usr/pkgsrc/geography/qgis afterwards.  (Really, I'd use a tool that
> finds packages with dependencies changed out from under them and runs
> make replace in all of them, in tsorted order.)
>
>> Although I build the latest gdal frequently on Linux I am still using
>> the system libgdal with the system qgis, which is a waste of an
>> opportunity to test, but I haven't attempted to keep rebuilding qgis
>> against each new gdal. Am I missing something ?
>
> I have never really been clear on GNU/Linux packaging (and don't know
> which flavor you are using, Debian, Fedora, Suse, or one of the boutique
> systems).  The pkgsrc attitude is source first, so the standard approach
> is for someone to "make package" (which downloads the sources, recurses
> into dependencies, unpacks, builds, installs in a destdir, and tars that
> up) and then "make package-install" or "make replace".  (Binary packages
> are available for popular OS/version/cpu combinations as a time-saving
> measure for people that want to use that.  With a vax, you usually have
> to build your own :-) )
>
> I have the impression that most/all? GNU/Linux packaging systems are
> also like this, and you can get the control files, and then modify them
> to point to the new gdal release, build a package, and then update your
> system with it.

That is correct for Red Hat and Ubuntu from personal experience;
and I assume also for other .rpm or .deb based systems.

There are newer package types like snap and flatpak which are supposed
to be flavour-agnostic (snap seems to be Debian and Ubuntu-only)
and allow *users* to install them without being root (typically using 
a container to isolate the machine from the application).

> For micro releases, I suspect you can just do this and then run qgis,
> checking with ldd to see what it links with.
>
> For non-micro, you would then want to get the control files for qgis and
> then build/replace a package.

Current Ubuntu (Questing, 25-10) comes with gdal 3.10.3 and qgis 3.40.5.

I like to keep several versions around so that I can check for 
regressions and other changed behaviour.
For example if I find a problem whilst testing the GDAL 3.12.2 release 
candidate, it is useful to be clear whether the problem was present
in say 3.11.x, 3.12.0 or 3.12.1.

As you say qgis can be made to use a different/newer micro release,
but I was hoping you had found a way around needing to rebuild qgis for
each mini-release of gdal.

[ This is also a killer for publishing out-of-tree gdal drivers
    and building drivers from source is beyond a substantial
    class of potential QGIS users :-(                             ]

> An alternative would be to set up another prefix, say /usr/osgeo, and
> then build gdal and install with --with-prefix=/usr/osgoe, and then
> qgis, passing in CPPFLAGS=-I/usr/osgeo, LDFLAGS="-L/usr/osgeo/lib
> -R/usr/osgeo/lib" and similar for pkg-config so the .pc files there will
> be found in preference to those in /usr.  This is not easy as sometimes
> packages assume they are on linux and only work in /usr.  pkgsrc, in
> addition to having control files to say how to build the package, has an
> accumulation of patches to remediate non-portability.  We (especially I)
> try to push these upstream.

Yes, I'm there for gdal, but I having been poking inside QGIS so haven't
wanted/needed to setup mutiple copies of that.

> I definitely encourage you to use the packaging system to build gdal and
> replace it, and rebuild other things as needed.  This ought to be
> straightforward and maybe it is.  It just seems to be culture that
> nobody does it.

That is great and what I did as a sysadmin for a department-full of 
machines, but with my developer hat on, both package systems only allow a 
single version at a time.

'alternatives' allows two or more well-coordinated packages to be 
installed at the same time and for the sysadmin to choose which one is
the system default, but this is designed for alternate implementations
rather that successive versions...

'environment-modules' allows a user (or script) to switch which version is
active in the current context. I have worked hard and have a single script
which builds my gdal drivers with two compilers for each of (up to) about 
a dozen micro-versions of gdal.
Since the package system is not designed for multiple concurrently
installed versions, I haven't bothered to package each version ...

> If you work out how to do this it would be great to explain to others.
> If it's just me that's confused and it's a well-trodden well-documented
> path a link would be great.

-- 
Andrew C. Aitchison                      Kendal, UK
                     andrew at aitchison.me.uk