Bug#1012088: libsdl2-dev is possibly missing dependencies

[Matthew Forrester]

Package: libsdl2-dev
Version: 2.0.20+dfsg-2build1
Severity: normal
X-Debbugs-Cc: woshilinma...@gmail.com

Dear Maintainer,

I think that libsdl-dev may possibly need its dependency list updating. I noticed the issue in Ubuntu, but the dependencies in Ubuntu are essentially the same as those in upstream Debian (apart from some things like libc and pkg-config which presumably apply to all packages), so I am reporting it to you too.

WHAT LED UP TO THE SITUATION?

I moved from Ubuntu 20.04 Focal Fossa to 22.04 Jammy Jellyfish. The Jammy version of this package (2.2.20+dfsg-2build1) is behind the Debian Sid version, but both versions have the same dependencies if there is a problem, then it is still there.

(This is how I discovered the issue, but there is probably a much more minimal reproduction case)
1. Downloaded the Simutrans-Extended repo: https://github.com/jamespetts/simutrans-extended
2. Downloaded the dependencies, at a minimum libsdl2-dev
3. Followed the instructions there for building with autotools

EXPECTED RESULTS

Simutrans-Extended compiles correctly, as it did on Focal Fossa.

ACTUAL RESULTS

When I tried to build it on Jammy Jellyfish, the build failed with the following errors from the linker:

/usr/bin/ld: cannot find -ldrm: No such file or directory
/usr/bin/ld: cannot find -lgbm: No such file or directory
/usr/bin/ld: cannot find -ldecor-0: No such file or directory

Installing Ubuntu's libdrm-dev, libgbm-dev, and libdecor-0-dev packages ("the 'missing' packages") solved that problem. But I wonder whether it might be a packaging bug. I follow Simutrans-Extended development quite closely and we have not intentionally introduced dependencies on those packages; I think they have been brought in by SDL2.

If a program using sdl2-dev used to be able to compile without the 'missing' packages, but now requires them, it seems to me that they are now dependencies of sdl2-dev. Or at least should be 'suggests'. But I am not an expert on either Debian packaging or SDL2.

COMMENTS

The 'missing' libraries are not direct dependencies of Simutrans. However, the sdl2-0-0 packages in Debian and Ubuntu have recently added dependencies on libgbm1, libdrm2, and libdecor-0-0.

Compare the Bullseye dependencies.... https://packages.debian.org/bullseye/libsdl2-2.0-0
......with the Bookworm dependencies: https://packages.debian.org/bookworm/libsdl2-2.0-0

However, the Bookworm and Sid libsdl2-dev packages do **not** list dependencies on the 'missing' -dev packages: https://packages.debian.org/bookworm/libsdl2-dev

I notice that SDL's own build guide lists those packages as dependencies for building SDL2 itself on Focal Fossa: https://github.com/libsdl-org/SDL/blob/main/docs/README-linux.md
But that change was made in February 2021 so it affects Ubuntu's version of SDL2 in Jammy, not Focal: https://github.com/libsdl-org/SDL/commit/2f4e9294aa260635d876b5699846adc458f555db
That change was before Bullseye was released so I am not sure how that fits with the Debian timescale.

I initially asked about this on AskUbuntu and a comment there confirmed that the required .so files are in (for example) libgbm-dev, not lib-gbm1: https://askubuntu.com/questions/1410876/is-ubuntus-libsdl2-dev-package-missing-dependencies-or-have-i-made-a-mistake?noredirect=1#comment2451919_1410876
That seemed to confirm that this might be a packaging/dependencies issue.

The downstream report for Ubuntu is here: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976198

Thank you for your time. I hope this feedback is helpful and not just my misunderstanding.

-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-33-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsdl2-dev depends on:
ii libasound2-dev 1.2.6.1-1ubuntu1
ii libc6 2.35-0ubuntu3
ii libdbus-1-dev 1.12.20-2ubuntu4
ii libegl1-mesa-dev 22.0.1-1ubuntu2
ii libgl-dev 1.4.0-1
ii libgles-dev 1.4.0-1
ii libglu1-mesa-dev 9.0.2-1
ii libibus-1.0-dev 1.5.26-4
ii libopengl0 1.4.0-1
ii libpulse-dev 1:15.99.1+dfsg1-1ubuntu1
ii libsdl2-2.0-0 2.0.20+dfsg-2build1
ii libsndio-dev 1.8.1-1.1
ii libudev-dev 249.11-0ubuntu3.1
ii libwayland-dev 1.20.0-1
ii libx11-6 2:1.7.5-1
ii libx11-dev 2:1.7.5-1
ii libxcursor-dev 1:1.2.0-2build4
ii libxext-dev 2:1.3.4-1build1
ii libxi-dev 2:1.8-1build1
ii libxinerama-dev 2:1.1.4-3
ii libxkbcommon-dev 1.4.0-1
ii libxrandr-dev 2:1.5.2-1build1
ii libxss-dev 1:1.2.3-1build2
ii libxt-dev 1:1.2.1-1
ii libxv-dev 2:1.0.11-1build2
ii libxxf86vm-dev 1:1.1.4-1build3

libsdl2-dev recommends no packages.

libsdl2-dev suggests no packages.

-- no debconf information

[Simon McVittie]

On Mon, 30 May 2022 at 02:52:27 +0100, Matthew Forrester wrote:
> /usr/bin/ld: cannot find -ldrm: No such file or directory
> /usr/bin/ld: cannot find -lgbm: No such file or directory
> /usr/bin/ld: cannot find -ldecor-0: No such file or directory

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.

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.

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

smcv

[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

[Simon McVittie]

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