Stephen Kelly wrote:
> However, the Raspberry Pi has libz.so in some funny locations:
>
> stephen@hal:~/rpi/rasp-pi-rootfs$ find -name "*libz*"
> ./lib/arm-linux-gnueabihf/libz.so.1
> ./lib/arm-linux-gnueabihf/libz.so.1.2.7
> ./usr/lib/arm-linux-gnueabihf/libz.so
> ./usr/lib/arm-linux-gnueabihf/libz.a
This doesn't affect only Qt, but could affect any CMake user trying to use a
library which depends on zlib on the Raspberry Pi.
find_package(ZLIB REQUIRED)
include_directories(${ZLIB_INCLUDE_DIRS})
if (NOT USE_FOO)
add_library(foo SHARED foo.cpp)
target_link_libraries(foo LINK_PRIVATE ${ZLIB_LIBRARIES})
export(TARGETS foo NAMESPACE FOO:: FILE fooTarget.cmake)
else()
set(CMAKE_INCLUDE_CURRENT_DIR ON)
include("${CMAKE_CURRENT_BINARY_DIR}/fooTarget.cmake")
set_property(TARGET FOO::foo APPEND PROPERTY
IMPORTED_LINK_DEPENDENT_LIBRARIES_NOCONFIG "${ZLIB_LIBRARIES}")
# set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} -Wl,-rpath-link,
${CMAKE_FIND_ROOT_PATH}/lib/arm-linux-gnueabihf")
add_executable(bar foo_user.cpp)
target_link_libraries(bar FOO::foo)
endif()
If execute that once with -DUSE_FOO=0 (and then make) and again with -
DUSE_FOO=1, the second make fails with
$ make
makeobj[0]: Entering directory `/home/stephen/dev/src/playground/cmake/rpi'
Linking CXX executable bar
/home/stephen/rpi/gcc-4.7-linaro-rpi-gnueabihf/bin/../lib/gcc/arm-linux-
gnueabihf/4.7.2/../../../../arm-linux-gnueabihf/bin/ld: warning: libz.so.1,
needed by libfoo.so, not found (try using -rpath or -rpath-link)
CMakeFiles/bar.dir/empty.cpp.o: In function `main':
empty.cpp:(.text+0x28): undefined reference to `compress2'
collect2: error: ld returned 1 exit status
make[2]: *** [bar] Error 1
make[1]: *** [CMakeFiles/bar.dir/all] Error 2
make: *** [all] Error 2
makeobj[0]: Leaving directory `/home/stephen/dev/src/playground/cmake/rpi'
I can 'fix' that by uncommenting the line which adds a manual -rpath-link
entry to the link flags. I don't think that's a very good fix though.
Another workaround would be to also find and add the path to /lib/arm-linux-
gnueabihf/libz.so.1, in addition to the /usr/lib/arm-linux-gnueabihf/libz.so
already found by FindZLIB.cmake and put that in the
IMPORTED_LINK_DEPENDENT_LIBRARIES too. That's basically what I described in
my initial mail.
I tried adding the needed directory to
IMPORTED_LINK_DEPENDENT_LIBRARIES_NOCONFIG, but that didn't add to the
rpath-link entries either:
set_property(TARGET FOO::foo APPEND PROPERTY
IMPORTED_LINK_DEPENDENT_LIBRARIES_NOCONFIG
"${ZLIB_LIBRARIES}"
"/lib/arm-linux-gnueabihf"
)
Do you think it should? At least that would be easier from a point of view
of using the information from the Qt mkspec files, which lists the
directories required to be in rpath-link already.
I also notice that IMPORTED_LINK_DEPENDENT_LIBRARIES_* entries are only
populated on export for targets, not for 'raw' targets. So
target_link_libraries(foo LINK_PRIVATE /lib/libz.so)
will not add /lib/libz.so to the IMPORTED_LINK_DEPENDENT_LIBRARIES_* on
export. Should it be allowed? It is possible to have a config file which
includes the target file, and then sets the property as a workaround, which
is similar to what I would be doing by populating it in the Qt config files.
If that shouldn't be allowed, do we need to design a better way to define
the rpath-link entries that need to be used when using a target foo? It
seems that some improvement in cmake would be beneficial here, and we just
need to decide on what the change to cmake should look like.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
