Static build of SDL2_ttf, linking to static build of SDL

SDL Development
1

My project contains SDL and SDL_ttf as submodules. The build process is supposed to create a static build of SDL2, then do the same for SDL_ttf, linking to the libSDL2.a file I just created. I’m using autotools for each (./configure --enable-static --disable-shared then make), though my own program just uses a single makefile.

The SDL2 build works great, but SDL2_ttf’s build system appears to assume that SDL2 has been installed (i.e. with make install), not just built. I specifically do not want to install SDL2 as part of this build process. I hoped I could resolve this with the –-with-sdl-prefix flag:

./configure --disable-shared --enable-static --with-sdl-prefix=$(PWD)/SDL --disable-sdltest

But unfortunately it’s insufficient because:

  1. the SDL2_ttf compilation commands were attempting to include files in SDL/include/SDL2, but the files live in SDL/include
  2. it looks for SDL/lib/libSDL2.a, but the library file is at SDL/build/.libs/libSDL2.a
  3. *** Warning: Linking the shared library libSDL2_ttf.la against the
    *** static library /Users/firstnamelastname/Documents/c/appname/SDL/lib/libSDL2.a is not portable!
    ===> This appears all over the SDL_ttf compilations, despite the fact that I passed –disable-shared and –enable-static to ./configure when building SDL_ttf

I could try to finagle the build system to fix all of these things individually and anything else that crops up after doing so, but I can’t tell if I’m near the end of the tunnel or if I’d be stuck in it for many more hours.

Is there a sensible way to do what I’m trying to do?

1 Like
2

I’m working around this now by invoking make install to “install” SDL in a new local subdirectory (SDL/installation) and then using that subdirectory as the sdl-prefix when building SDL_ttf. As far as I can tell, all that make install is doing now is invoking an external utility to copy a bunch of files and shuffle them around into a new hierarchy, which is a bit silly, but seems harmless enough and is certainly preferable to manually fiddling with a bunch of environment variables or the configure script itself. If anyone knows a less hacky way I’d be interested, but this works for now.

(I should mention that I’m aware of the dynapi guidance. I don’t think the technical concerns apply to my project, because it’s not a game and I’m not going to distribute through Steam or any other game distribution network, and many if not most of my users will not be using SDL for anything else. If the ethical concerns have anything to do with giving due credit to the SDL project, I have “built with SDL” or similar and links to libsdl.org all over my source code and documentation, and my project is free software, so hopefully those count for something! But I’m willing to hear feedback if anyone wants to educate me more about it, I admit to not fully understanding either concern.)