Package: cmake Version: 3.12.3-3 Severity: important Control: affects -1 src:openal-soft
Dear maintainer, Consider this simple test case: $ apt-cache policy libsndio-dev libsndio-dev: Installed: 1.5.0-2 [...] $ cat test.c $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) find_library(SOUNDIO_LIBRARY NAMES sndio) SET(FOO_OBJS test.c) ADD_LIBRARY("foo" SHARED ${FOO_OBJS}) TARGET_LINK_LIBRARIES("foo" PRIVATE ${SOUNDIO_LIBRARY}) When run on amd64 or any non-hurd architecture, it generates the following link flags: $ cat CMakeFiles/foo.dir/link.txt /usr/bin/cc -fPIC -shared -Wl,-soname,libfoo.so -o libfoo.so CMakeFiles/foo.dir/test.c.o -lsndio But when run on hurd-i386, the last flag is different and wrong: $ cat CMakeFiles/foo.dir/link.txt /usr/bin/cc -fPIC -shared -Wl,-soname,libfoo.so -o libfoo.so CMakeFiles/foo.dir/test.c.o /usr/lib/i386-gnu/libsndio.so Such a flag is a problem when the referenced .so file is actually a symlink. GCC does not resolve it and generates a dependency literally on libsndio.so. Such dependencies cause problems with Debian packages. One problem is that .so files are usually in -dev packages, while the dependent packages depend only on the library package. Another problem is that dpkg-shlibdeps does not generate any dependency at all in this case. Example from openal-soft build log on hurd-i386: dpkg-shlibdeps: warning: cannot find library /usr/lib/i386-gnu/libsndio.so needed by debian/libopenal1/usr/lib/i386-gnu/libopenal.so.1.19.1 (ELF format: 'elf32-i386' abi: '0101000300000000'; RPATH: '') and then: libopenal1_1.19.1-1_hurd-i386.deb --------------------------------- [...] Depends: libopenal-data (= 1:1.19.1-1), libatomic1 (>= 4.8), libc0.3 (>= 2.27) -- Dmitry Shachnev
signature.asc
Description: PGP signature