Your message dated Wed, 31 Oct 2018 21:15:43 +0300
with message-id <[email protected]>
and subject line Re: Bug#912443: cmake: Generates wrong link flags on hurd-i386
has caused the Debian Bug report #912443,
regarding cmake: Generates wrong link flags on hurd-i386
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
912443: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912443
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Hi Brad!
On Wed, Oct 31, 2018 at 01:39:35PM -0400, Brad King wrote:
> Linking a library by absolute path is okay (and preferred) if the library
> has a proper SONAME. What is the output of
>
> $ readelf -d /usr/lib/i386-gnu/libsndio.so | grep SONAME
Thanks for the hint. The output is empty.
Looks like sndio configure script does not set SONAME on hurd:
https://sources.debian.org/src/sndio/1.5.0-2/configure/#L56
I am now closing this bug, and I will file a new one on sndio.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
--- End Message ---
