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

[Simon McVittie]

On Tue, 10 Dec 2019 at 11:51:26 +, Simon McVittie wrote:
> When I get a chance to work on this again, I'll add an autopkgtest that
> does what neverball relies on, and re-test with that.

Sorry for the delay. Here's that test:
https://salsa.debian.org/sdl-team/libsdl2/merge_requests/6

On Sun, 19 Jan 2020 at 23:11:18 +0100, Felix Geyer wrote:
> On 10.12.19 23:18, Hugh McMaster wrote:
> > At this point, I don’t see anything preventing us from adding the extra
> > include path
> 
> I've pushed this change to the git repo:
> https://salsa.debian.org/sdl-team/libsdl2/commit/6f58f10282cf9b9af567ec520f0d2c4dc368dbea

I have confirmed that the test in !6 passes with the SDL currently in
unstable (before !5), fails after !5 but without 6f58f102, and passes
again with that commit added.

> On 10.12.19 23:18, Hugh McMaster wrote:
> > Neverball could also be patched to call pkg-config with SDL2_ttf, which,
> > IIRC, has both include paths already (since SDL2_ttf requires SDL2).

It would be great if SDL-dependent packages would phase out the pattern of
using sdl2-config for SDL and a hard-coded -l for the smaller libraries
like SDL2_ttf, and start using pkg-config. However, that would require
some mass-bug-filing and patches. 6f58f102 means we can avoid the
incompatible change, avoiding that MBF being a blocker for solving #909740.

smcv

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

[Felix Geyer]

Hi Hugh,

On 10.12.19 23:18, Hugh McMaster wrote:

At this point, I don’t see anything preventing us from adding the extra
include path, although I’m going to do some tests builds of various
SDL2-based programs to be certain.

Neverball could also be patched to call pkg-config with SDL2_ttf, which,
IIRC, has both include paths already (since SDL2_ttf requires SDL2).
Unfortunately, this won’t resolve the broader problem.


I've pushed this change to the git repo:
https://salsa.debian.org/sdl-team/libsdl2/commit/6f58f10282cf9b9af567ec520f0d2c4dc368dbea

Did you have time to test-build some reverse-dependencies of SDL2?

Cheers,
Felix

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

[Simon McVittie]

On Tue, 10 Dec 2019 at 21:56:51 +1100, Hugh McMaster wrote:
> As a test, I built and installed SDL2 with Simon's patch, then built
> and installed SDL2-ttf. That worked fine out of the box.
> 
> Neverball failed to build because it couldn't find
> /usr/include/SDL2/SDL_ttf.h, which is, of course, not part of the
> default search path.

With which of my patches? I sent three merge requests (!3, !4, !5) with
different ways to solve multiarch coinstallability, each with different
advantages and disadvantages, in the hope that at least one of them would
be considered acceptable and unblock progress on this bug.

I would expect that !5 (the one that Felix has now merged, using
$PKG_CONFIG) and !4 (closer to what you and Adrian suggested, using $CC)
would break the neverball use-case when used as-is, as Felix pointed out.
This is because they do not have -I/usr/include/SDL2 in
`sdl2-config --cflags`, so #include  won't work. To avoid that
regression, if !5 (or !4) is still the preferred option, one option is
to hard-code -I/usr/include/SDL2 in addition to -I${libdir}/SDL2.

However, I would have expected !3 (which would now mean reverting the
main commit from !5 and applying !3 instead) to work OK for neverball's
use-case, because it leaves -I/usr/include/SDL2 in `sdl2-config --cflags`,
the same as in the non-multiarch-capable implementation currently in
the archive; so I'd be surprised if this breaks neverball. If this is
the one you tested, please could you indicate the exact patch or git
commit you used?

When I get a chance to work on this again, I'll add an autopkgtest that
does what neverball relies on, and re-test with that.

I still like !3 best, but I'm happy to fix !5 (or even !4) to avoid the
neverball regression if the SDL2 maintainers would prefer that.

> Wouldn't it be easier to just patch sdl2.pc to add
> ${prefix}/include/SDL2 to CFLAGS, as Felix suggested? That should
> catch all #includes.

That would be one way to modify !5 so that neverball works, yes.

> Also, this small addition has far less overhead than multiple copies
> of the SDL2 headers.

I'm not sure I understand what you're proposing or opposing here. If
you have two architectures' versions of libsdl2-dev installed, !4 and
!5 both duplicate the headers from the main SDL2 library; !3 does not.

I don't think anyone has proposed a solution that would involve
duplicating the SDL2 headers within one architecture.

Rebuilding SDL2_ttf, SDL2_mixer etc. with
--includedir=/usr/include/${multiarch} would duplicate those libraries'
headers between architectures, although those libraries' headers are a
lot smaller than the main SDL2 library's headers anyway, so the impact
of doing so is small when compared with choosing !4 or !5 over !3.
However, I agree that this is not a great solution, because it would
require more coordination between packages than just changing libsdl2.

smcv

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

[Simon McVittie]

On Tue, 10 Dec 2019 at 08:50:56 +, Simon McVittie wrote:
> I suppose if one of the SDL2_foo family uses #include "SDL_bar.h"
> and expects to find an adjacent SDL2 that way, or if
> something tries to second-guess the compiler and read
> header files directly, that might be a reason to revert
> https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5
> (the one that goes via pkg-config) and apply
> https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3 (my original
> proposal with a forwarding header) instead

For what it's worth, Fedora has a similar forwarding header, except that
they don't have an equivalent of /usr/include/${multiarch}, so they have
to hard-code every supported architecture in their forwarding header:

https://src.fedoraproject.org/rpms/SDL2/blob/master/f/SDL_config.h
https://src.fedoraproject.org/rpms/SDL2/blob/master/f/SDL2.spec#_106

smcv

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

[Simon McVittie]

On Mon, 09 Dec 2019 at 19:08:05 +0100, Felix Geyer wrote:
> On a second though I fear having the include files of libsdl2 and libsdl2-*
> in different paths will break some build systems.
> 
> A random example I quickly found:
> https://sources.debian.org/src/neverball/1.6.0+git20180603-2/Makefile/

Good point. Build systems like this assume that sdl2-config is sufficient
to find all the SDL2_foo family, not just the main library.

> One option would be to add -I/usr/include/SDL2 to sdl2-config or pkg-config
> but I'm not sure if that would cover all cases.

If neverball was using `pkg-config --cflags SDL2_ttf` then that would just
give it -I/usr/include/SDL2, so it seems like that ought to be sufficient.

I suppose if one of the SDL2_foo family uses #include "SDL_bar.h"
and expects to find an adjacent SDL2 that way, or if
something tries to second-guess the compiler and read
header files directly, that might be a reason to revert
https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5
(the one that goes via pkg-config) and apply
https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3 (my original
proposal with a forwarding header) instead - that's the only solution
I could see that keeps most SDL headers in the same place they have
always been.

(Alternatively, you could switch all the SDL2_foo packages to use the
multiarch include directory "unnecessarily", just to make them consistent,
but that's more avoidable uploads and header duplication.)

smcv

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

[Felix Geyer]

On 08.12.19 14:03, Hugh McMaster wrote:

After reviewing the four proposals, I too prefer the pkg-config solution to
the others. That said, your proposal using the Debian-specific header is
wonderfully simple.

In the longer term, I'm hoping there will be a push at some point to no
longer install sdl2-config, since that will simplify some of the issues
encountered here. Upstream have made it optional to install sdl2-config in
2.0.10.


On a second though I fear having the include files of libsdl2 and libsdl2-*
in different paths will break some build systems.

A random example I quickly found:
https://sources.debian.org/src/neverball/1.6.0+git20180603-2/Makefile/

It calls "sdl2-config --cflags" and then would fail to find SDL_ttf.h (from
the libsdl2-ttf-dev package) in /usr/include/SDL2.

One option would be to add -I/usr/include/SDL2 to sdl2-config or pkg-config
but I'm not sure if that would cover all cases.

Cheers,
Felix

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

[Felix Geyer]

Hi Simon,

On 27.11.19 20:18, Simon McVittie wrote:
> In an attempt to unblock this bug I've implemented several versions of a
> solution to it, so that the SDL2 maintainers can choose their favourite
> and merge it.
>
> [...]
>
> Do the SDL2 maintainers have any comments on these MRs, or preference
> between them?

Thanks a lot for putting in all the work to implement, test and summarize them!

I'm leaning towards patching sdl2-config to call pkg-config
(https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5).
My hope is that most software uses pkg-config or cmake to find SDL2.
This solution wouldn't introduce any weirdness (forwarding header) into
the default use cause.

I'll merge that one unless someone wants to convince me otherwise soon ;)

Cheers,
Felix

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

[Simon McVittie]

In an attempt to unblock this bug I've implemented several versions of a
solution to it, so that the SDL2 maintainers can choose their favourite
and merge it.

On Sun, 30 Sep 2018 at 22:17:05 +0100, Simon McVittie wrote:
> Ugh, I'd missed that there's a third API for building dependent software
> (the CMake files). The autopkgtest that I added should ideally test this
> one too, but I think that'll probably need a proper CMake build system
> (at least one CMakeLists.txt), not just a one-liner?

New autopkgtest proposed in
. It passes
for the current state of libsdl2-dev, and for all my implementations.

On Sun, 30 Sep 2018 at 19:08:26 +0100, Simon McVittie wrote:
> https://salsa.debian.org/smcv/libsdl2/commits/multiarch-forwarding-header
> 
> 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.

Now at .
I think this is still my preferred option, but the others are also viable.

On Sun, 30 Sep 2018 at 22:02:59 +0300, Adrian Bunk wrote:
> Wouldn't the least invasive option be a combination of
> 1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
> 2. the sdl2-config patching from Hugh

I've implemented this alternative at
.

I've also implemented a version of this suggestion,
but using $PKG_CONFIG instead of $CC in sdl2-config:
. I think
this is maybe a bit nicer than !4?

Other interested developers are of course welcome to propose something
better - I'm sure there are other possibilities that I've missed.

Do the SDL2 maintainers have any comments on these MRs, or preference
between them?

Thanks,
smcv

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

[Anton Vorobyov]

As of today's debian testing, libsdl2-dev is the only wine build dependency 
which is not multiarch-installable

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

[Anton Vorobyov]

Hi, are there any ETAs on resolving this issue? It prevents me from building 
32+64 bit Wine.

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

[Simon McVittie]

On Sun, 30 Sep 2018 at 22:02:59 +0300, Adrian Bunk wrote:
> Wouldn't the least invasive option be a combination of
> 1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
> 2. the sdl2-config patching from Hugh

Maybe. You'd have to patch sdl2-config somewhat more extensively than
Hugh's patch, though, to remove the references to the configured
@includedir@ (which would vary by architecture if you use that
--includedir, making /usr/bin/sdl2-config non-co-installable until it
was removed).

Does someone want to put together and test a complete implementation
of this?

> When doing 1. the build system will use the correct paths in the 
> pkg-config and cmake files.

Ugh, I'd missed that there's a third API for building dependent software
(the CMake files). The autopkgtest that I added should ideally test this
one too, but I think that'll probably need a proper CMake build system
(at least one CMakeLists.txt), not just a one-liner?

I think the forwarding header should work OK with this approach, and your
plan with --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) would
obviously also work, but any approach that involves patching the .pc.in
file would also have to patch the .cmake.in file.

smcv

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

[Adrian Bunk]

On Sun, Sep 30, 2018 at 07:08:26PM +0100, Simon McVittie wrote:
>...
> 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//SDL2, arrange for the pkg-config metadata to
> include -I/usr/include//SDL2 (and possibly /usr/include/SDL2)
> in the Cflags, and arrange for sdl2-config to output the same CFLAGS as
> -pkg-config without itself having architecture-varying content,
> most likely by using a `cc -print-multiarch` trick similar to the one
> Hugh suggested.
>...

Wouldn't the least invasive option be a combination of
1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
2. the sdl2-config patching from Hugh

When doing 1. the build system will use the correct paths in the 
pkg-config and cmake files.

The only remaining issue would be sdl2-config, and this would be covered 
by 2.

This sounds better to me than adding some Debian-specific header.

It would move all headers under the multiarch location, but 1.5 MB 
diskspace additional usage are a non-issue for someone compiling for 
more than one architecture.

Anything I miss here?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[Simon McVittie]

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
-lSDL2
$ CC='gcc -m32' sdl2-config --cflags --libs
-I/usr/include/SDL2 -D_REENTRANT
-lSDL2

Also available here:
https://salsa.debian.org/smcv/libsdl2/commits/multiarch-forwarding-header

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//SDL2, arrange for the pkg-config metadata to
include -I/usr/include//SDL2 (and possibly /usr/include/SDL2)
in the Cflags, and arrange for sdl2-config to output the same CFLAGS as
-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).

smcv
>From db7d3e2dc883e44f1305c9c61a334502b40e9f7b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 30 Sep 2018 15:17:47 +0100
Subject: [PATCH] Make libsdl2-dev Multi-Arch: same, with working
 

Fix inclusion of  by installing a Debian-specific
forwarding header that includes an appropriate architecture-specific
copy of SDL_config.h.

Closes: #909740
---
 debian/SDL_config.h| 4 
 debian/changelog   | 9 +
 debian/control | 1 +
 debian/libsdl2-dev.install | 2 ++
 debian/rules   | 5 +
 5 files changed, 21 insertions(+)
 create mode 100644 debian/SDL_config.h

diff --git a/debian/SDL_config.h b/debian/SDL_config.h
new file mode 100644
index 000..bbad0f5
--- /dev/null
+++ b/debian/SDL_config.h
@@ -0,0 +1,4 @@
+/* Debian-specific indirection to an architecture-specific copy of
+ * SDL_config.h in one of the compiler's default include directories.
+ * Please do not include _real_SDL_config.h directly. */
+#include 
diff --git a/debian/changelog b/debian/changelog
index 51774eb..c8454ae 100644
--- a/debian/changelog
+++