Bug#909740: libsdl2-dev: No longer multi-arch co-installable

Simon McVittie smcv at debian.org
Sun Sep 30 19:08:26 BST 2018

On Sun, 30 Sep 2018 at 15:54:05 +0100, Simon McVittie wrote:
> For the short term, I'm preparing a NMU that reverts the multiarch change
> and adds an autopkgtest that confirms that the package is usable, because
> libsdl2-dev is currently unusable, and that's a considerably worse bug
> than not being multiarch-friendly.

I have done this, so I'm moving this discussion to #909740. (Adrian,
please let us know if you'd like to be removed from Cc now that SDL2
should have stopped causing FTBFSs.)

> After that, I think it would make most sense for the SDL maintainer
> team to choose one of the working approaches to multiarch, check that
> it does in fact work, and use it to re-close the multiarch bug.

I attach a possible patch for one of the proposed approaches (the
forwarding header that I suggested). I have confirmed that this does not
break compilation of a SDL2 game engine (I used ioquake3) and the
autopkgtest added in my NMU passes. I haven't done a "full stack" test
of cross-compilation yet, but it's symmetrical across architectures, so
hopefully it should work:

    $ x86_64-linux-gnu-pkg-config --cflags --libs sdl2
    -D_REENTRANT -I/usr/include/SDL2 -lSDL2
    $ i686-linux-gnu-pkg-config --cflags --libs sdl2
    -D_REENTRANT -I/usr/include/SDL2 -lSDL2
    $ sdl2-config --cflags --libs
    -I/usr/include/SDL2 -D_REENTRANT
    $ CC='gcc -m32' sdl2-config --cflags --libs
    -I/usr/include/SDL2 -D_REENTRANT

Also available here:

I prefer this approach because it's relatively self-contained, and
doesn't require us to carry non-upstreamable patches to upstream code
or rely on a relatively obscure Debian-specific compiler option.

The alternative would be to modify the build system so that
at least SDL_config.h (and possibly all the headers) are in
/usr/include/<triplet>/SDL2, arrange for the pkg-config metadata to
include -I/usr/include/<triplet>/SDL2 (and possibly /usr/include/SDL2)
in the Cflags, and arrange for sdl2-config to output the same CFLAGS as
<triplet>-pkg-config without itself having architecture-varying content,
most likely by using a `cc -print-multiarch` trick similar to the one
Hugh suggested.

I started to prototype a patch for that myself, but it
quickly becomes fairly ugly: for example, Hugh's patch from
is not sufficient, because sdl2.pc will still contain only
the non-multiarch @includedir@, unless SDL2 is configured with
--includedir=/usr/include/${DEB_HOST_MULTIARCH}, in which case sdl2-config
will need a different patch to make it non-architecture-varying. As a
result, I'm leaving it to someone who advocates this approach to prepare
a candidate patch for it if they want to.

If someone would prefer this approach, please put together
a complete, tested patch that passes at least these tests:

* libsdl2-dev:amd64 and libsdl2-dev:i386 are co-installable
* the debian/tests/build autopkgtest passes
* x86_64-linux-gnu-pkg-config --cflags --libs sdl2,
  i686-linux-gnu-pkg-config --cflags --libs sdl2 and
  sdl2-config --cflags --libs give reasonable results
* if using Hugh's approach with $CC,
  "CC=i686-linux-gnu-cc sdl2-config --cflags --libs" and
  "CC='gcc -m32' sdl2-config --cflags --libs" also give
  reasonable results

and preferably also test "full stack" cross-compilation of some SDL2
application or game.

SDL2 maintainers: Before releasing a version of SDL2 with *anyone's*
patch applied - including mine! - please make sure that you have tested
it thoroughly, and in particular successfully compiled and run at least
one SDL2 application or game against it.

You should also consider applying Helmut's patch from #907711, which is
on a similar theme (enabling cross-compilation) and seems correct and
upstreamable (but please note that I haven't actually tested it).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-libsdl2-dev-Multi-Arch-same-with-working-SDL_co.patch
Type: text/x-diff
Size: 2808 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-sdl-maintainers/attachments/20180930/4349c030/attachment.patch>

More information about the Pkg-sdl-maintainers mailing list