On Mon, 30 May 2022 at 23:05:19 +0100, Matthew Forrester wrote:
> On 30/05/2022 12:08, Simon McVittie wrote:
> > Is this software linking to SDL statically? As far as I can see from the
> > pkg-config file, these are going to be required for static linking but not
> > for the more typical dynamic linking to shared libraries.
>
> No, it is dynamically linked to SDL2.
>
> "readelf -d ./simutrans-extended" gives:
> 0x0000000000000001 (NEEDED) Shared library: [libSDL2-2.0.so.0]
>
> "readelf --dyn-syms" returns the SDL2 symbols that are used in our code.
>
> "ldd ./simutrans-extended" gives
> libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
> (0x00007f912a885000)
>
> Ldd also lists the three 'missing' packages. Readelf contains no references to
> the 'missing' packages, nor does our codebase have any calls to "drm_" or
> "libdecor_" functions. So I don't see why the linker is trying to link those
> libraries at all. It seems that something about dynamically linking to SDL2 is
> pulling in these dependencies.
This seems like a bug in the Simutrans Extended build system. Dynamic
linking to SDL2 should only require the -dev package for the direct
dependency, SDL2 itself:
(new way)
$ pkg-config --libs sdl2
-lSDL2
(old way)
$ sdl2-config --libs
-lSDL2
The indirect dependencies like libdrm and libdecor are an implementation
detail of SDL2, so on platforms with high-quality shared library
implementations (like Linux), this way to link only needs the runtime
library libdrm.so.2 or libdecor-0.so.0, not the -dev symlink libdrm.so
or libdecor-0.so.
My understanding is that all modern OSs like *BSD, Windows and macOS
have similar behaviour, with only the filenames differing (e.g. *.dll
and *.lib on Windows), and the only times you need to pass a complete list
of recursive dependencies to the linker are:
* when linking to static libraries
* maybe when using 1990s proprietary Unixes like AIX or HP/UX
As a result, SDL2 will only require you to link to indirect dependencies
like libdecor and libdrm if you tell the build tool that you are going
to be linking statically:
(new way)
$ pkg-config --libs --static sdl2
-lSDL2 -lm -ldl -lasound ... -ldecor-0 ...
(old way)
$ sdl2-config --static-libs
(same output)
The Simutrans Extended build system is not one that I am familiar
with (it combines Autoconf with a hand-written Makefile, rather than
using Automake), but it looks like it sets STATIC = 1 by default, and
as a result calls `pkg-config sdl2 --libs --static` or
`sdl2-config --static-libs`? It shouldn't be doing that unless it's
intentionally linking SDL2 as a static library.
libsdl2-dev *should* have all the required dependencies for static linking
(to the extent that it's possible - it isn't straightforward with Automake
or a plain Makefile), so the missing -dev dependencies were a bug, but
it's a bug that shouldn't have affected Simutrans Extended unless you
were deliberately linking statically.
In libsdl2_2.0.22+dfsg-4 I added a regression test that statically
links SDL2 into a simple CMake project, which should mean any missing
dependencies for static linking in future versions will be caught
before upload.
smcv
