[CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J. V. Bertin]

Eric Noulard wrote:

> AFAIK the explanation you gave. CMake does not seem to play with -l or -L
> options.

As Rolf said above, apparently it does.

> the FindPNG.cmake shipped with CMake does not do that either.

Indeed, it sets PNG_LIBRARY to the path of libpng, and PNG_LIBRARIES to the 2 
required libraries (libpng and libz), both with full path. There would be no 
problem if that data ended up in the linker command.

> Which version of CMake are you using?

3.8.2

> Which version of digikam are you trying to compile?

5.6.0

> Did you try to
> 
> message(STATUS "show me  PNG_LIBRARIES=${PNG_LIBRARIES}")

Yes, the variable contains the correct 2 paths.

> Now I'm lost. If the culprit is a clang feature/bugs then why did you
> suspect CMake in the frst place?

Because at the end of the day that doesn't matter : CMake must generate 
Makefiles that work, and thus has to work around known issues or peculiarities 
in the compilers it support. That could be through hardwired exceptions, but in 
this case could also be by providing a way to disable rewriting those library 
specifications.

Maybe there is, I haven't yet found any documentation whatsoever about the 
conditions under which CMake will (supposedly) replace a /path/to/libfoo.so 
libspec with -lfoo .

> Does the command line produced by the CMake generator you use (?makefile
> ?ninja ?) contains
> the full path to lib or -L + -l flags?

No. It contains -lpng -lz but no -L flag. See the more specific discussion in 
cmake-devel ("FindPNG.cmake doesn't return a LIBRARY_DIR variable").

R.