[cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable

[Rolf Eike Beer]

Am 2017-07-12 13:35, schrieb René J.V. Bertin:
> Hi,
> 
> I routinely use cmake to build projects for installation into a prefix
> (/opt/local) and that use libraries from that location which also
> exist in the system locations (typically in older versions, in that
> case).
> 
> I thus have .pc files under /opt/local which generate linker
> instructions of the type "-L/opt/local/lib -lfoo".
> 
> You'd expect this should work, but (too) often I still get linker
> errors about symbols not being found which upon verification are in
> fact provided by the intended library. In that case the
> -L/opt/local/lib is typically given only once on the linker command
> line ("way" before the corresponding -l argument), or not at all. See
> the example below, where I don't see the -L option at all (linker
> output and data from CMakeCache.txt after the HUGE linker command).
> 
> Initially I thought this was a case where one shouldn't filter out
> identical -L options because the linker could limit their scope to
> just the -l option immediately following the -L, but in this case it
> appears that FindPNG.cmake simply doesn't consider the possibility
> that libpng might be found in a location that isn't in the standard
> library search path. IOW, FindPNG.cmake doesn't return a
> PNG_LIBRARY_DIR variable, and provides the full path only in an
> obsolete variable (PNG_LIBRARY). And for some reason, the command
> `target_link_libraries(digikamcore ... ${PNG_LIBRARIES} ...)` is
> translated into `-lpng -lz` .
> Is that a bug or feature?

First, FindPNG.cmake doesn't care about pkg-config files, if that is bug 
or feature depends on your personal things. CMake will detect the 
library using the full path (as it has done), and construct proper -L 
and -l from that. It doesn't happen here, which makes me suspect that 
you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being 
the better version). It seems to me like the -lpng you see comes from 
QtWebkitWidgets, which would also need to be linked against your library 
anyway, as things could break in funny ways otherwise (no idea how 
stable the libPNG API is).

Eike
--