On Thu, 5 Feb 2026, Greg Troxel via gdal-dev wrote:
Andrew C Aitchison via gdal-dev <[email protected]> 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
[email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
