SDL2: Removing too much?

[thomas]

I just tested VirtualBox-KVM (​https://github.com/cyberus-technology/virtualbox-kvm) on LFS.

It turns out that VBox7 (which VBox-KVM is based on) relies on SDL2 and links against libSDL2main.a. Unfortunatly, this lib is deleted by

rm -v /usr/lib/libSDL2*.a

in the book. Changing that to

rm -v /usr/lib/libSDL2{,_test}.a

solves this issue but i cannot say whether the remaining deleted libs are needed somewhere else (as libSDL2main.a is).

_{Btw, VirtualBox as such works pretty fine on a LFS host, just a few additional packages (libIDL, acpica, gsoap, libtpms, libvncserver) required to install.}

[pierre]

What is the reason that makes this program unable to link to a shared library?

[thomas]

hmm, i don't know, it simply expect libSDL2main.a to be there (there is no libSDL2main.so). It looks to me that this lib is some kind of a core functionality for SDL programs.

[pierre]

Could it be that libSDL2.so does not contain the functions that are in libsDL2main.a?

[pierre]

Yes it does. In /usr/include/SDL2/SDL_main.h, we have, for our "OS" (GDK):

   On GDK, SDL provides a main function that initializes the game runtime.

   Please note that #include'ing SDL_main.h is not enough to get a main()
   function working. You must either link against SDL2main or, if not possible,
   call the SDL_GDKRunApp function from your entry point.

So the answer to the subject question might be "yes"...

Scratch that: our system is LINUX, it seems, but yes, the function SDL_main is defined in /usr/include/SDL2/SDL_main.h

[ken@…]

Looking at gentoo, ​https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/libsdl2/libsdl2-2.28.5-r1.ebuild which seems to be their latest version, their install has

# Do not delete the static .a libraries here as some are
# mandatory. They may be needed even when linking dynamically

As a continued hater of static libraries used by other packages (hello, kde!) I continue to be reluctant to delete static libs - in my case I rename them to whatever.a.hidden so that I can temporarily reinstate them where needed.

Since I'm talking about static libs, I'll also mention that if one wanted to use wasm for recent firefox (I have no interest in doing that unless forced) it would appear to need not only a shed-load of extra llvm-related packages, but also static libz.a, which we remove in LFS - deleting unneeded things is fine if they really are not needed, but rarely saves significant space on a modern desktop build and might (as in this case) prevent the use of some other packages.

[Xi Ruoyao]

The problem with static libraries is not they waste space. The problem is when we update a static library we need to relink everything using it, and it's very hard to figure out which packages are using it.

Consider the use of libz.a of Firefox as an example. We'll need to rebuild Firefox whenever zlib is updated with a security fix if we use libz.a. The WASM sandbox won't automatically fix the security vulnerabilities, it only turns down for exanple an RCE to a DoS, but a DoS is still a vulnerability and we still need to rebuild Firefox to fix it. This is some kind of bullsh*t IMO. If they think zlib is not secure enough they can re-implement it (maybe in Rust) instead of translating it to WASM and pretending it would be safe.

[Xi Ruoyao]

And why not they make a shared libSDL2main.so? There is nothing preventing defining main() in a shared library, at least on GNU/Linux. Maybe again some stupid "portability" thing like libtool.

[ken@…]

Replying to Xi Ruoyao:

Consider the use of libz.a of Firefox as an example. We'll need to rebuild Firefox whenever zlib is updated with a security fix if we use libz.a. The WASM sandbox won't automatically fix the security vulnerabilities, it only turns down for exanple an RCE to a DoS, but a DoS is still a vulnerability and we still need to rebuild Firefox to fix it. This is some kind of bullsh*t IMO. If they think zlib is not secure enough they can re-implement it (maybe in Rust) instead of translating it to WASM and pretending it would be safe.

Fair comment, although I don't think zlib is part of what they sandbox in WASM, it's only a requirement for something in the convoluted llvm+extras build system where soembody decided to require a static lib.

[ken@…]

Replying to Xi Ruoyao:

And why not they make a shared libSDL2main.so? There is nothing preventing defining main() in a shared library, at least on GNU/Linux. Maybe again some stupid "portability" thing like libtool.

Many years ago, I got a hack from the still-much-missed Andy of this parish to create a shared lib from one of the minor mozilla libs which was only supplied as a static lib but was needed by something (probably needed by firefox). But doing that there is no guarantee that things will still work if the library changes. If an upstream doesn't provide a shared lib, my current view is that it is better to make the static lib available, and to note what uses it in case there is a vulnerability to fix.

[pierre]

After studying the virtualbox build system, it appears that it unconditionally includes -lSDL2main in addition to -lSDL2 even if it is not needed. So this is where the fault is, not in BLFS...

My understanding of the issue is that everything that is needed is included in libSDL2.so and SDL2.h, and nothing more needs to be included.

Note that there is a --disable-static option in configure, and maybe it would be cleaner to use that rather than removing the static libraries afterwards.

[pierre]

FWIIW, --disable-static does not prevent installation of libSDL2main.a and libSDL2_test.a...