[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-ports
Subject:    Re: ld.lld vs ld.bfd and cmake - missing shlib version in NEEDED
From:       George Koehler <kernigh () gmail ! com>
Date:       2018-11-29 3:48:02
Message-ID: 20181128224802.3fa32c42837e26f44a1478db () gmail ! com
[Download RAW message or body]

On Thu, 29 Nov 2018 00:28:11 +0000
Stuart Henderson <stu@spacehopper.org> wrote:

> $ objdump -p /usr/local/bin/zint|grep NEEDED
>   NEEDED      libzint.so
>   NEEDED      libpng.so.17.5
>   NEEDED      libz.so.5.0
>   NEEDED      libm.so.10.1
>   NEEDED      libc.so.93.0

I don't know.  This might happen because some libraries in OpenBSD
(like libzint and libpng) don't have DT_SONAME.

In other ELF systems, a shared library has its name and version
number in DT_SONAME.  The linker opens a symbolic link (like
libterminfo.so -> libterminfo.so.1.0) and reads the DT_SONAME to know
the version number.  It copies this DT_SONAME to DT_NEEDED.

Like in NetBSD:
$ objdump -p /usr/lib/libterminfo.so | grep SONAME
  SONAME               libterminfo.so.1
$ objdump -p /usr/bin/tmux | grep terminfo
  NEEDED               libterminfo.so.1

In OpenBSD, there is no libpng.so symlink, so the linker opens
libpng.so.17.5.  There's no DT_SONAME.  The linker knows that the
basename is libpng.so.17.5, but the linker might or might not use
the basename as DT_NEEDED.

If I remember correctly, if ld.bfd links to a library without
DT_SONAME, then the rules are:
 - If you use cc -L/usr/local/lib -lpng, then ld.bfd uses the
   basename libpng.so.17.5 as DT_NEEDED.  This is correct.
 - If you use cc /usr/local/lib/libpng.so.17.5, then ld.bfd uses
   the absolute path /usr/local/lib/libpng.so.17.5 as DT_NEEDED.
   This is weird but might still work.
 - If (inside some project) you use cc subdir/libwhat.so.0.0, then
   ld.bfd uses the relative path subdir/libwhat.so.0.0 as DT_SONAME.
   This might break the build because some executable has subdir in
   its rpath, and needs subdir/libwhat.so.0.0 in its rpath, but fails
   because subdir/subdir/libwhat.so.0.0 doesn't exist.

The rules in ld.lld might be different.  I don't know.  This weirdness
only happens on OpenBSD, because other ELF systems always put
DT_SONAME in their shared libraries.

Some build systems (like CMake and Meson) like to run cc with absolute
or relative paths to shared libraries.  They rely on DT_SONAME to set
DT_NEEDED to just the basename.  OpenBSD's port of devel/cmake has
local patches:
 - patch-Modules_CMake{C,CXX}Information_cmake seems to remove the
   -Wl,-soname=... so shared libraries don't get DT_SONAME.
 - patch-Source_cmComputeLinkInformation seems to link to libraries
   with -L... -l... instead of absolute paths.

-- 
George Koehler <kernigh@gmail.com>

[prev in list] [next in list] [prev in thread] [next in thread]