I'm trying to understand an error that I'm seeing on GCC 4.9.2 (on ubuntu) at link time.
The specific scenario is compiling a new version of GDAL with pdfium support. pdfium is built as a static library.
The pdfium build works, but a link time error occurs with GDAL. It looks like:
/bin/bash /home/bradh/devel/gdal.git/gdal/libtool --mode=link g++ gdalinfo.lo commonutils.lo /home/bradh/devel/gdal.git/gdal/libgdal.la -o gdalinfo libtool: link: g++ .libs/gdalinfo.o .libs/commonutils.o -o .libs/gdalinfo /home/bradh/devel/gdal.git/gdal/.libs/libgdal.so -L/home/bradh/pdfium/install -L/home/bradh/pdfium/install/lib/pdfium -L/usr/local/lib -L/usr/lib -lpdfium -lfpdfapi -lfpdftext -lformfiller -lpdfwindow -lfxedit -lfpdfdoc -lfxcodec -lfx_libopenjpeg -lfx_lcms2 -lfx_libjpeg -lfx_zlib -lfdrm -lfxge -lfreetype -lfx_agg -lfxcrt -lbigint /usr/local/lib/libfreexl.so -lodbc -lodbcinst -lkmldom -lkmlbase -lkmlengine -lkmlconvenience -lminizip -luriparser /usr/lib/x86_64-linux-gnu/libexpat.so -lxerces-c -ljasper -lnetcdf -lhdf5 /usr/lib/libmfhdfalt.so /usr/lib/libdfalt.so -lgif -lgeotiff /usr/lib/x86_64-linux-gnu/libtiff.so -lpng -lpq -lrt /usr/local/lib/libspatialite.so -ldl /usr/local/lib/libproj.so -lm -lpthread -lz /usr/local/lib/libgeos_c.so /usr/local/lib/libgeos.so /usr/lib/x86_64-linux-gnu/libsqlite3.so -lpcre /usr/lib/x86_64-linux-gnu/libcurl.so -lxml2 -pthread /usr/bin/ld: .libs/gdalinfo: hidden symbol `_ZN13CFDF_Document12CreateNewDocEv' in /home/bradh/pdfium/install/lib/pdfium/libfpdfapi.a(fpdf_parser_fdf.o) is referenced by DSO /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status
I understand what the error means (see What does exactly the warning mean about hidden symbol being referenced by DSO?), and I know how to fix it - turn off hidden visibility everywhere, or set the two problem classes to have default visibility (by attribute or declspec).
What I don't understand is why those specific classes are referenced at all - they aren't used directly in GDAL source code.
Using nm, per a comment, they do appear in the gdal.so.20.0.0 shared library:
U _ZN13CFDF_Document12CreateNewDocEv
(U == undefined). That is consistent with the "is referenced" part from the linker error, but isn't telling me why it is referenced.
Perhaps there is some inlining that means that they are used - but now I'm guessing, and I'd prefer not to. Especially since I appear to be guessing wrong.
So the question is whether there is some way to debug the linker logic - somehow find out why the linker wants to try to resolve those symbols?
