Bug 234893 - graphics/gdal: ld: error: undefined symbol: GDALWarpAppOptionsSetQuiet
Summary: graphics/gdal: ld: error: undefined symbol: GDALWarpAppOptionsSetQuiet
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Sunpoet Po-Chuan Hsieh
Depends on:
Reported: 2019-01-12 11:13 UTC by O. Hartmann
Modified: 2019-08-18 04:24 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (sunpoet)

patch-GDALmake.opt.in (356 bytes, patch)
2019-01-15 18:08 UTC, rob.kruus
no flags Details | Diff
files/patch-GDALmake.opt.in (358 bytes, patch)
2019-01-15 20:21 UTC, rob.kruus
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2019-01-12 11:13:03 UTC
On FreeBSD 13.0-CURRENT #74 r342956: Sat Jan 12 09:13:37 CET 2019 amd64 updating/installing port graphics/gdal (recently updated from 2.2.X to 2.4.X) fails compiling with:

c++ -I/usr/ports/graphics/gdal/work/gdal-2.4.0/port -I/usr/ports/graphics/gdal/work/gdal-2.4.0/gcore -I/usr/ports/graphics/gdal/work/gdal-2.4.0/alg -I/usr/ports/graphics/gdal/work/gdal-2.4.0/ogr -I/usr/ports/graphics/gdal/work/gdal-2.4.0/ogr/ogrsf_frmts -I/usr/ports/graphics/gdal/work/gdal-2.4.0/gnm -I/usr/ports/graphics/gdal/work/gdal-2.4.0/apps -DHAVE_AVX_AT_COMPILE_TIME -DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -O2 -pipe  -fPIC -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing   -DLIBICONV_PLUG -isystem /usr/local/include -std=c++11  -fPIC  -Wall -Wextra -Winit-self -Wunused-parameter -Wformat -Werror=format-security -Wno-format-nonliteral -Wshorten-64-to-32 -Wshadow -Werror=vla -Wdate-time -Wnull-dereference -Wextra-semi -Wcomma -Wfloat-conversion -Wdocumentation -Wno-documentation-deprecated-sync -Wunused-private-field -Wmissing-prototypes -Wmissing-declarations -Wnon-virtual-dtor -Woverloaded-virtual -fno-operator-names -Wzero-as-null-pointer-constant -Wimplicit-fallthrough  -I/usr/ports/graphics/gdal/work/gdal-2.4.0/frmts/vrt -DGNM_ENABLED -DLIBICONV_PLUG -I/usr/local/include -isystem /usr/local/include -I/usr/ports/graphics/gdal/work/gdal-2.4.0/port -I/usr -I/usr/include  -DGDAL_COMPILATION -I/usr/local/include/json-c -I/usr/ports/graphics/gdal/work/gdal-2.4.0/ogr/ogrsf_frmts/geojson -I/usr/ports/graphics/gdal/work/gdal-2.4.0/ogr/ogrsf_frmts/generic -I/usr/ports/graphics/gdal/work/gdal-2.4.0/gnm -DHAVE_GEOS=1 -I/usr/local/include -c -o gdalwarp_bin.o gdalwarp_bin.cpp
c++ -L/usr/local/lib -fstack-protector  gdalwarp_bin.o  -L/usr/ports/graphics/gdal/work/gdal-2.4.0 -lgdal  -lcrypto -lproj -ljson-c -L/usr/local/lib -lgeos_c  -lsqlite3 -ljasper -lgif -ljpeg -lgeotiff -ltiff -lpng -lcfitsio -L/usr/local/lib -lpq -llzma -lz -L/usr -L/usr/lib -lpthread -lm -lrt -ldl -L/usr/local/lib   -L/usr/local/lib -lcurl                  -o gdalwarp
ld: error: undefined symbol: GDALWarpAppOptionsSetQuiet
>>> referenced by gdalwarp_bin.cpp
>>>               gdalwarp_bin.o:(main)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [GNUmakefile:94: gdalwarp] Error 1
gmake[3]: Leaving directory '/usr/ports/graphics/gdal/work/gdal-2.4.0/apps'
gmake[2]: *** [GNUmakefile:109: apps-target] Error 2
gmake[2]: Leaving directory '/usr/ports/graphics/gdal/work/gdal-2.4.0'
*** Error code 1

make[1]: stopped in /usr/ports/graphics/gdal
Comment 1 Rainer Hurling 2019-01-12 15:18:31 UTC
For me it helps to first deinstall the old version and then install version 2.4.0.

BTW, the build error does not occur, if only default options (JASPER) are enabled ...
Comment 2 rob.kruus 2019-01-15 18:08:02 UTC
Created attachment 201164 [details]
Comment 3 rob.kruus 2019-01-15 18:10:19 UTC
It is because of the library search paths, the patch allows it to build.

c++ -L/usr/local/lib -fstack-protector  gdalwarp_bin.o ...

should be

c++ -L/usr/ports/graphics/gdal/work/gdal-2.4.0 -fstack-protector  gdalwarp_bin.o ...

for all the executables in the app directory.
Comment 4 rob.kruus 2019-01-15 20:21:55 UTC
Created attachment 201168 [details]

Messed up the last one it seems -- this one seems to work.

It might also be done in the post-patch section of the port, where GDALmake.opt.in is already altered.

@${REINPLACE_CMD} -e '/^LDFLAGS/ s|@LDFLAGS@|-L@abs_top_builddir@ -fstack-protector|' ${WRKSRC}/GDALmake.opt.in
Comment 5 Sunpoet Po-Chuan Hsieh freebsd_committer 2019-01-18 17:33:05 UTC
(In reply to O. Hartmann from comment #0)

Please deinstall first, then build and install. BTW, you have to list the options if not using the default option.

(In reply to Rainer Hurling from comment #1)

I could build this port successfully with JASPER disabled (all others unchanged) on 11.2.
Comment 6 Sunpoet Po-Chuan Hsieh freebsd_committer 2019-01-24 17:12:05 UTC
(In reply to rob.kruus from comment #4)

Thanks. I haven't tested it yet but can't we just prepend -L@abs_top_builddir@ to @LDFLAGS@?
Comment 7 rob.kruus 2019-01-27 05:11:40 UTC
(In reply to Sunpoet Po-Chuan Hsieh from comment #6)

Quite possibly, I am not sure if that was one thing I tried when trying to find a simple solution.
But not replacing it might have the build still look outside the build dir for libs when linking (and PREFIX/lib is already included later in the make generate linking command).

-L@abs_top_builddir@ -fstack-protector  gdalwarp_bin.o ...


-L@abs_top_builddir@ -L/usr/local/lib -fstack-protector  gdalwarp_bin.o ...

(G)Makefile magic is certainly not my forte.
Comment 8 Sunpoet Po-Chuan Hsieh freebsd_committer 2019-01-28 21:47:38 UTC
(In reply to rob.kruus from comment #7)

I think the complete patch should include both CFLAGS/CPPFLAGS/CXXFLAGS and LDFLAGS.
And we have to revert it after build stage to keep installed GDALmake.opt clean.
Comment 9 Walter Schwarzenfeld freebsd_triage 2019-08-08 11:01:18 UTC
Comment 10 rob.kruus 2019-08-14 19:40:36 UTC
I am for whatever works, and I am by no means expert in ports or make systems, but I can usually make things work for my use cases.
Comment 11 O. Hartmann 2019-08-18 04:24:20 UTC
In the meanwhile, on all relevant systems we use (CURRENT and 12-STABLE), LLVM including its linker and, as far as I know, binutils has changed and moved on. It seems the reported problem has gone with these changes.