[gdal-dev] CMake: undefined reference to symbol dlerror

[Javier Jimenez Shaw]

Sorry for the noise. After some more research, it looks like the old GDAL
compilation/linking was hiding a problem with boost (in particular
boost::dll::program_location()). Now with the new GDAL cmake compilation,
the dependency with libdl is probably different, and our code does not
link. The linker error messages were not helpful enough.

It is not a problem in GDAL. Sorry.

Cheers,
Javier.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 2 May 2022 at 14:12, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:

> Hi Even
>
> If I understood the example you mention correctly, it is a direct
> dependency of GDAL: the executable test_cpp links directly with GDAL.
> Our problem is that we have a library (ioimage), that links with GDAL. The
> error appears when we try to compile/link tests_unit_ioimage, that
> depends on ioimage, that depends on GDAL.
>
> Cheers,
> Javier
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
>
> On Mon, 2 May 2022 at 10:29, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>>
>> Le 29/04/2022 à 11:30, Javier Jimenez Shaw a écrit :
>>
>> We have a link problem on Linux when using GDAL transiently. If we link
>> the unit tests for a library which depends on GDAL, i.e. an executable
>> which transiently depends on GDAL through our library, we get the following
>> linker error:
>>
>> /usr/bin/ld:
>> libs/ioimage/tests/CMakeFiles/tests_unit_ioimage.dir/unit/writers/test_geoTiffWriter.cpp.o:
>> undefined reference to symbol 'dlerror@@GLIBC_2.2.5'
>> /usr/bin/ld: /lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO
>> missing from command line
>>
>> We need to add -ldl to the linker line after GDAL in order to resolve
>> the linker problem. This can be done when adding the property
>>
>>   INTERFACE_LINK_LIBRARIES "dl"
>>
>> to the GDAL::GDAL imported target in GDAL-targets-release.cmake (this is
>> a generated file); apparently it is not enough to add dl to the
>> IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE property.
>>
>> Does GDAL depend publicly on dl?
>>
>> Not that I'm aware of.
>>
>> Our CI runs ./autotest/postinstall/test_cmake.sh which in particular has
>> a ./autotest/postinstall/test_cpp/CMakeLists.txt that has GDAL has a
>> dependency
>>
>> Perhaps you could check how your setup is different from that ?
>>
>> We do not find the proper way to patch GDAL's CMake code to add that
>> dependency in the generated config file.
>>
>> Thanks
>> Javier
>>
>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>> Entre dos pensamientos racionales
>> hay infinitos pensamientos irracionales.
>>
>>
>> _______________________________________________
>> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220503/12909a83/attachment.htm>