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

[Eric Noulard]

2017-07-12 21:14 GMT+02:00 René J. V. Bertin <rjvbertin at gmail.com>:

> Rolf Eike Beer wrote:
>
> >> It seems that clang handles that variable in a somewhat different manner
> >> than GCC does. Even in a very simple call on the commandline (including
> the
> >> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
> >> libraries, where GCC puts it before the 1st -l option.
> >
> > Welcome to the work of link_directories(). This is exactly the reason to
> avoid
> > it: it always causes trouble.
>
> digikam (that's the project we're talking about) doesn't use neither that
> nor
> target_link_directories. And if CMake simply used the libraries as found
> and
> specified in the target_link_libraries() call I wouldn't have run into
> problems
> either.
>

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

the FindPNG.cmake shipped with CMake does not do that either.
Current digikam does use ${PNG_LIBRARIES} where he should now use  PNG::PNG
imported lib.
(introduced in CMake 3.5.0 though)

Which version of CMake are you using?

Which version of digikam are you trying to compile?

Did you try to

message(STATUS "show me  PNG_LIBRARIES=${PNG_LIBRARIES}")

in the digikam CMakeLists.txt in order to be sure of the content of this in
your case.



> I did raise a flag on the clang ML though. But whether it's a clang bug or
> feature the fact remains that ideally one should be able to tell cmake
> exactly
> what to do, without it trying to outguess the operator.
>

Now I'm lost. If the culprit is a clang feature/bugs then why did you
suspect CMake in the frst place?
Does the command line produced by the CMake generator you use (?makefile
?ninja ?) contains
the full path to lib or -L + -l flags?


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170712/0a27909f/attachment.html>