Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
Rolf Eike Beer wrote: > First, FindPNG.cmake doesn't care about pkg-config files, if that is bug Yes, I noticed that after I wrote the remark about the pkg-config files, and didn't think to remove it (= I diagnosed the issue while writing the message). > 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 >From the CMake file (digikam-5.6.0/core/app/CMakeLists.txt): target_link_libraries(digikamcore PUBLIC Qt5::Core Qt5::Gui Qt5::Xml Qt5::Widgets Qt5::Sql Qt5::WebKitWidgets Qt5::PrintSupport Qt5::Concurrent KF5::Solid KF5::WindowSystem KF5::ConfigGui KF5::CoreAddons KF5::Service KF5::XmlGui KF5::I18n # Required by CImg which use pthread internally. ${CMAKE_THREAD_LIBS_INIT} ${LCMS2_LIBRARIES} # filters ${TIFF_LIBRARIES} ${PNG_LIBRARIES} ${EXIV2_LIBRARIES} libdng libraw ) > 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 It does and is, but I don't find a reference to libpng in its cmake modules (nor in any other of Qt5's modules, for that matter). So while your hypothesis seems reasonable I don't see where the -lpng would be added by Qt's modules. (FWIW, QtWebKit also has a .pc file, but it doesn't add - lz after -lpng so unless someone reorders the link library order that file cannot be the source of the issue either.) I've asked a more generic question about fully-qualified path conversion to -lfoo on the general ML ("/path/to/libpng.so automatic conversion to -lpng"). R. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
On Wed, Jul 12, 2017 at 14:22:40 +0200, Rolf Eike Beer wrote: > 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. CMake prefers using full paths to libraries it finds, so I don't think it would turn a full path into a `-L` and `-l` flag pair. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
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 -- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
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? cd /path/todigikam/work/build/core/app && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/digikamcore.dir/link.txt --verbose=1 /opt/local/bin/clang++-mp-4.0 -fPIC -O3 -g -DNDEBUG -std=c++11 -m64 -std=c++0x -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fexceptions -UQT_NO_EXCEPTIONS -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warning s -Wl,--enable-new-dtags -Wl,-R,/opt/local/lib -shared -Wl,-soname,libdigikamcore.so.5.6.0 -o libdigikamcore.so.5.6.0 CMakeFiles/digikamcore.dir/utils/digikam_debug.cpp.o CMakeFiles/digikamcore.dir/digikamcore_autogen/moc_compilation.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserverstarter.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseservererror.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserver.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfigloader.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfig.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineactiontype.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineerrorhandler.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineguierrorhandler.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_ src.dir/engine/dbengineparameters.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginebackend.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginesqlquery.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineaccess.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/tags/tagregion.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdb.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbchemaupdater.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbbackend.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbaccess.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/digikamdatabasecore_src_autogen/moc_compilation.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/dimgloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pngloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jp egloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/tiffloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/rawloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/ppmloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/qimageloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pgfloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.