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.

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

We believe that the bug you reported is fixed in the latest version of
libsdl2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1012088@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated libsdl2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 30 May 2022 16:43:30 +0100
Source: libsdl2
Architecture: source
Version: 2.0.22+dfsg-4
Distribution: unstable
Urgency: medium
Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1011583 1012088
Changes:
 libsdl2 (2.0.22+dfsg-4) unstable; urgency=medium
 .
   [ Gianfranco Costamagna ]
   * Ignore tests if the system is Ubuntu and architecture arm64,
     requiring some real new hw to complete successfully
     (workaround for LP: #1976288)
 .
   [ Simon McVittie ]
   * d/control: Remove Sam Hocevar from Uploaders,
     with thanks for past contributions (Closes: #1011583)
   * d/tests/installed-tests: Assert that at least one test was run
   * d/control: Add missing dependencies for static linking
     (Closes: #1012088, LP: #1976198)
   * d/tests/cmake: Exercise static linking to SDL
   * Standards-Version: 4.6.1 (no changes required)
   * Only skip testatomic on Ubuntu, not the rest of the test suite.
     This lets us get at least some confidence that the package is working.
Checksums-Sha1:
 0d17a7cee123822f2630aee6514ffe5db7bd3d01 3169 libsdl2_2.0.22+dfsg-4.dsc
 6e5112a5b0a2b22aaa6727a5c81dfb597ca5c891 41892 libsdl2_2.0.22+dfsg-4.debian.tar.xz
 2648591cf8cee8b97571c3a42d3986833c1fb292 10694 libsdl2_2.0.22+dfsg-4_source.buildinfo
Checksums-Sha256:
 3b02d011cf7e404c1337737d5d99e47aaad4ea09b6c1cf6ff3b748a08fdadefd 3169 libsdl2_2.0.22+dfsg-4.dsc
 e5a0443091b606298862175114d5064a59287baa0924ce8d0c94273776c4627a 41892 libsdl2_2.0.22+dfsg-4.debian.tar.xz
 768523e2a1d92f8dbc642dae623ce3c599259dac9fa05ea3ae32ccfa6ecd431b 10694 libsdl2_2.0.22+dfsg-4_source.buildinfo
Files:
 dfb07646660c413ab27d4068a30ed96d 3169 libs optional libsdl2_2.0.22+dfsg-4.dsc
 0c16a6aadad0a04f0ac9dafcbd0ceda4 41892 libs optional libsdl2_2.0.22+dfsg-4.debian.tar.xz
 b125ab548732d724dda224434cd9a5f9 10694 libs optional libsdl2_2.0.22+dfsg-4_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmKU718ACgkQ4FrhR4+B
TE83NRAAmLLJxUkBwMGNbAVo8x57YFliXYU9D+pko+/wqB1x/Mm7Em5r/hUbSwJN
irunEPvxUoLOf7qkA6SpsWPKb8G3Us96gScNxkgvfvGrdItNg8mpEG+/Gz7CrlbI
5x5t+GVxAFTOYARmdZ3lRjSDsgnHCMCJzOoPbxwP4xU8mUzDQ4/CUeEUpd4uztoT
UbwyCgJnxtPBPl24QBinrfc3OcFOJ+HagJ77JDlI0I7qN+P037ZsH++QBrjlNxZY
9saeyntRjLgOdlCiMN37kBt+ydy+41bbtdm3pKZOSoW24pxX95cAdCCjRITBvTcC
/IJC7TCnk3dN0MAUIfbIaJcxbLV94a06B/7OOfgAjtcDiilrtykG4kDGszySBJR1
ca4PUSolK63WE/qXBQ7HLbd4wnPF5TflD7WFTrqrMHpwo9GBwc0DXrVE2wWQ9ziR
+6eizWKhhLlZPX4QpQD8+GIOUrhbAoI/PiwjYM3DjTich2IUyKw9PBSIAPP3ZCR1
Fp5hKCm5XceLBoJvyTvAy5vTtGANQpKfXzkXk616nnpRlqsztz372Myk+0hlHkJe
YlnXQ+vwyOU8jPMq/uHRskPJVl+ZP/PG5SJmRfo9+97JZsHVof1eEkCi5YHnuBKR
AkJe7GgHgl04MYoo6DUJnIl04O/ttBK3y8adKTGJwrvzLr9XiYY=
=Vzoq
-----END PGP SIGNATURE-----

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

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).

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?

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

Matthew

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

We believe that the bug you reported is fixed in the latest version of
libsdl2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1012088@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated libsdl2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 31 May 2022 13:26:32 +0100
Source: libsdl2
Architecture: source
Version: 2.0.22+git20220530+g3c3c025+dfsg-1
Distribution: experimental
Urgency: medium
Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1011583 1012088
Changes:
 libsdl2 (2.0.22+git20220530+g3c3c025+dfsg-1) experimental; urgency=medium
 .
   * Merge packaging from unstable
   * New upstream git snapshot
   * Refresh patches
 .
 libsdl2 (2.0.22+dfsg-4) unstable; urgency=medium
 .
   [ Gianfranco Costamagna ]
   * Ignore tests if the system is Ubuntu and architecture arm64,
     requiring some real new hw to complete successfully
     (workaround for LP: #1976288)
 .
   [ Simon McVittie ]
   * d/control: Remove Sam Hocevar from Uploaders,
     with thanks for past contributions (Closes: #1011583)
   * d/tests/installed-tests: Assert that at least one test was run
   * d/control: Add missing dependencies for static linking
     (Closes: #1012088, LP: #1976198)
   * d/tests/cmake: Exercise static linking to SDL
   * Standards-Version: 4.6.1 (no changes required)
   * Only skip testatomic on Ubuntu, not the rest of the test suite.
     This lets us get at least some confidence that the package is working.
Checksums-Sha1:
 2b120d2cf5268f6a3df7b3af3a74d2322bddeb33 3353 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.dsc
 c17ec0c5a1509a6b0cee7346b1a8fd4f3789875a 4641304 libsdl2_2.0.22+git20220530+g3c3c025+dfsg.orig.tar.gz
 024b93164dbb79bd30ea9396154dfab678b33295 32148 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.debian.tar.xz
 498f57fbec2a3c441eb02c13ccd0b57348e8b8df 10799 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1_source.buildinfo
Checksums-Sha256:
 788df9fc2ed8f10617f68c8c86eee0bab70ac2eef1bd9ca0089caecc50e29b76 3353 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.dsc
 3e524116057fa082cc76a0171fbff6534b31095502645faabb882f028a50209e 4641304 libsdl2_2.0.22+git20220530+g3c3c025+dfsg.orig.tar.gz
 9855fe7cb250dcbfe6ae07daa360e913b952d8714dae9d407fb50b95a94ca1f6 32148 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.debian.tar.xz
 31762a9339e3ae663397c9594b2803a0954f8c14e6092c2eb2203f20beeb24f6 10799 libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1_source.buildinfo
Files:
 a56c624bb5566770fa1f7729cbf6d2db 3353 libs optional libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.dsc
 baa5aba6842f0a8fec7c7267fe38f7e4 4641304 libs optional libsdl2_2.0.22+git20220530+g3c3c025+dfsg.orig.tar.gz
 dd5f679e20bfbfddd3e422f3a5c3b57c 32148 libs optional libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1.debian.tar.xz
 b0849ef603bcf1b755716d2b65a730b3 10799 libs optional libsdl2_2.0.22+git20220530+g3c3c025+dfsg-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmKWEEQACgkQ4FrhR4+B
TE/w+Q/8DIB8JMbi175mjYoJ8TH0c2blBkClq9sAFOM7zD/yivAnL8jVowz2DdLw
wR2hgC1644uxvyfRBFfm9/vzkamXqTPWT/ItLAche8ca/QwzOYNbXjsRptlJS94k
SfUVnaH9IvgaxYiWWvanHAuN5YaIR/t3m8Fa/2YHCLqtBWBBSVnFGEG0xGMwbOgy
8EkR5C5IcmSaRDOdZPDPFkk+D8qRlQJLhrgp8htTg3+b0aI7/mQfBLKVc6UB5ko0
Fo1ZkKp0LZpeBpTmOdzWbl5dmlYiet8zWebzcX3DsHmGOcsc6RjtMp5zsa59cQpO
9TmobL7tC6jVGbjm27Hjqeh0uHIGqrsbk4d+cyl7Jxz6kkWyBxRv9mKvFpFcDovH
0JhlVYNa9epenW3i47nEeQrlp8P16LUA/Rl/dN02j3tTj0u+gc8t0RH7SXDNZusF
0dZmz/A22P4rzPbhR+5AFc30yLri77rPE80uv9adTlHhMzwrdWBxwwgypjj0s4DJ
BVLMu7HWyIUAJAw+WuG0WSF4yE2XJqEiVpLfEi39tHlxiVhOlGiRfv8OgMI7E5lf
dV+M5LojPwe8ZwpIQX7j3VcU1gGYEwqcHFhpjLZ4IT0Tq7UFZ5O4fWq++lVeNMQQ
4IWnhDBi5aljzrD+uVp7QjugnMKsK1YbK4vd3nCtXtNkbKGqd7g=
=7YpS
-----END PGP SIGNATURE-----