package/sdl_mixer: disable libmad support for static build only

Following the discussion on the ML [1], all package using SDL_mixer will unlikely forget to link with -lmad.

[...]sysroot/usr/lib/libSDL_mixer.a(music_mad.o): In function `read_next_frame':
music_mad.c:(.text+0xbc): undefined reference to mad_stream_buffer' music_mad.c:(.text+0xd0): undefined reference to mad_frame_decode' music_mad.c:(.text+0x134): undefined reference to `mad_timer_add'

Until SDL_mixer and other package using it are not fixed, disable libmad support for static build only.

Fixes:
http://autobuild.buildroot.net/results/e09/e09ea3a64d396bbc855acf7c07fcbea28fb2395d

[1] http://lists.busybox.net/pipermail/buildroot/2016-February/153442.html

Romain,

Quoted 8 lines · Romain Naour

Following the discussion on the ML [1], all package using SDL_mixer will unlikely forget to link with -lmad.

[...]sysroot/usr/lib/libSDL_mixer.a(music_mad.o): In function `read_next_frame':
music_mad.c:(.text+0xbc): undefined reference to mad_stream_buffer' music_mad.c:(.text+0xd0): undefined reference to mad_frame_decode' music_mad.c:(.text+0x134): undefined reference to `mad_timer_add'

Quoted 7 lines

Until SDL_mixer and other package using it are not fixed, disable libmad support for static build only.

Fixes:
http://autobuild.buildroot.net/results/e09/e09ea3a64d396bbc855acf7c07fcbea28fb2395d

[1] http://lists.busybox.net/pipermail/buildroot/2016-February/153442.html

I am not sure whether this sort of patch is the good option. Yes, it avoids the autobuilder failure, but it doesn't really fix the problem itself. We could say it's a good temporary solution for 2016.02, but on the other hand, once this patch gets merged, we will most likely forget that this problem exists.

So I'm hesitating between:

1/ Applying your patch, and just forget about this issue, since we
probably don't care much anyway.

2/ Applying your patch, and asking you to fill in a bug report in our
bug tracker so that we don't forget about the issue.

3/ Not applying your patch, so that we keep the issue in our
autobuilder failures until someone fixes it.

Peter, what do you think?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

I don't think this workaround is necessary at all. Adding a 'Libs.private' section to SDL_mixer.pc and fixing packages that depend on SDL_mixer so that they use pkg-config doesn't seem too complicated. Currently only chocolate-doom, lbreakout2, ltris and prboom depend on it.

I'll work on a patch for chocolate-doom now and handle the other 3 later.

This is obviously the best option. Unfortunately, many of those packages are not maintained, so we can't upstream the patches you're talking about...

That's a good point. Well, at least chocolate-doom is being actively maintained, so we'll be able to upstream a patch in that case.

As for the other 3, do you think keeping patches for them in buildroot could turn out to be a hassle in the long run?

Thomas, Romain,

I don't think this workaround is necessary at all. Adding a 'Libs.private' section to SDL_mixer.pc and fixing packages that depend on SDL_mixer so that they use pkg-config doesn't seem too complicated. Currently only chocolate-doom, lbreakout2, ltris and prboom depend on it.

I'll work on a patch for chocolate-doom now and handle the other 3 later.

Regards,
Rodrigo