(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
