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.
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.
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.
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.
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.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
