Bug#1012088: Fwd: Bug#1012088: libsdl2-dev is possibly missing dependencies

[Matthew Forrester]

 (Simon, apologies, you will get two copies of this reply - this is the
copy through Debian BTS)

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.

As far as I can tell the only library that we might statically link to is
libpthreads (something to do with cross-compiling, which is not what I'm
doing here).

> SDL cannot be used in a completely statically-linked executable, because
> some of its dependencies are only available as shared libraries, but
> SDL itself can be linked statically by some build systems.

As far as I can tell, this issue occurs while dynamically linking to SDL2.

Do you think that I should report this behaviour upstream to SDL?

> (Either way, it's a SDL packaging bug, and I'll add the missing
> -dev dependencies in a future upload.)

Many thanks for your prompt response and action. SDL is a great tool for us.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-sdl-maintainers/attachments/20220530/da220388/attachment.htm>