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
