This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to include modplug via "libmodplug/modplug.h" (sdl2_mixer-modplug-include.patch, text/plain, 2014-07-03 23:47:20 +0000, 1245 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-10-06 23:20:05 +0000, wrote:

Hi,

(You're missing the option for 2.0 version for SDL_mixer in the bug tracker).

We have this building problem in Debian:

dh_auto_configure -- --enable-music-cmd --enable-music-mod --enable-music-mod-modplug --disable-music-mod-mikmod --enable-music-mp3 --disable-music-mp3-smpeg --enable-music-mp3-mad-gpl --enable-music-ogg --enable-music-wave --enable-music-midi-fluidsynth --enable-music-midi-timidity --enable-music-midi-native --disable-music-flac-shared --disable-music-fluidsynth-shared --disable-music-mod-modplug-shared --disable-music-ogg-shared

[...]
checking for MODPLUG... yes

[...]
libtool: compile: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -pipe -Wall -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_SIGNAL_H -DHAVE_SETBUF -fvisibility=hidden -DHAVE_FORK -DCMD_MUSIC -DWAV_MUSIC -DMODPLUG_MUSIC -DMID_MUSIC -DUSE_TIMIDITY_MIDI -I./timidity -DUSE_FLUIDSYNTH_MIDI -DOGG_MUSIC -DFLAC_MUSIC -DMP3_MAD_MUSIC -c mixer.c -fPIC -DPIC -o build/.libs/mixer.o
In file included from mixer.c:38:0:
dynamic_modplug.h:24:21: fatal error: modplug.h: No such file or directory
#include "modplug.h"
^
compilation terminated.
make[1]: *** [build/mixer.lo] Error 1

Full log in: http://aws-logs.debian.net/ftbfs-logs/2013/10/06/libsdl2-mixer_2.0.0+dfsg1-1_unstable.log

This was working in the recent past since 2.0 release until now, I am not sure of why. It seems to be missing "-I../whatever/modplug" (I guess that it's the right solution) or having the directory in the #include (which is probably wrong unless libmodplug is installed in the system default include path, e.g. /usr/include/modplug).

The line in configure.in is:

    EXTRA_CFLAGS="$EXTRA_CFLAGS -DMODPLUG_MUSIC $MODPLUG_CFLAGS"

whereas for mikmod is:

    EXTRA_CFLAGS="$EXTRA_CFLAGS -DMOD_MUSIC `$LIBMIKMOD_CONFIG --cflags`"

Given that modplug also provide pkg-config file, it's probably a good idea that configure.in uses it.

Can you please comment/advise?

By the way, modplug is now the default, right? According to ./configure it should be.

On 2013-10-18 07:19:38 +0000, Sam Lantinga wrote:

Any luck with this? We're using the standard PKG_CHECK_MODULES macro, which is defined in acinclude/pkg.m4

On 2013-10-18 19:32:13 +0000, wrote:

Sorry but I don't follow.

I didn't have time to work on the issue and nobody else suggested a fix, if that's what you mean with if I/we had any luck.

By saying that "We're using the standard PKG_CHECK_MODULES macro", do you mean that in the line below, that macro injects into $MODPLUG_CFLAGS and contains "-I/usr/include/libmodplug"? And that, if "-I/usr/include/libmodplug", it's because somehow the pkg-config call didn't emit it?

EXTRA_CFLAGS="$EXTRA_CFLAGS -DMODPLUG_MUSIC $MODPLUG_CFLAGS"

That seems to match what is happening. Reviewing the build logs in my machine and in a dozen other architectures supported, it looks like the "-I" flag is not being emitted.

Please confirm me that this is what you are saying, I will look into it.

On 2013-10-18 20:57:14 +0000, wrote:

The issue seems to be with this commit from upstream that was recently incorporated into Debian:

http://sourceforge.net/p/modplug-xmms/git/ci/master/tree/libmodplug/libmodplug.pc.in?diff=78a4032ef85ea0e7cda8c26ae20fefb277a81096

Do you think that this is wrong? That's the current head, it was not reverted afterwards. I am surprised that nobody else (using other distributions or OSs) is affected.

On 2013-10-19 08:20:51 +0000, Sam Lantinga wrote:

It looks like they expect everyone to include <libmodplug/modplug.h>

Unfortunately this means we can't install modplug.h in a non-standard location, such as including directly from the unpacked source distribution, as we do for Android.

For Debian, as a hack, you can add /usr/include/libmodplug to the include directory, but that seems fragile...

Thoughts?

On 2013-10-19 11:07:59 +0000, wrote:

Yes, I think that this is a bad idea in general for the reasons that you mention.

I also found that there are popular libraries which work in the same way, for example curl:

Example with https: http://curl.haxx.se/libcurl/c/https.html

#include <stdio.h>
#include <curl/curl.h>

Their pkg-config does not add the "/usr/include/curl" dir (relevant parts):

---

prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: libcurl
URL: http://curl.haxx.se/
Libs: -L${libdir} -lcurl
Libs.private: -lidn -lrtmp -lssh2 -lgcrypt -lgnutls -Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -llber -llber -lldap -lz
Cflags: -I${includedir}

Invocation:

$ pkg-config --cflags libcurl
[empty line]
$ pkg-config --cflags --libs libcurl
-lcurl

So I guess that different projects do things in different ways, and I don't know if it will be possible to convince them. Do you know if there's a canonical document of good practices to try to steer the situation in one way or another?

Other than that, it's not a bit problem for us, we will add a little patch in the packaging or issue a "-I" somewhere in the rules file. The situation only becomes annoying if many of the libraries require tweaks, and worse, if they change these things more or less randomly as it happened now. I guess that Fedora, Suse etc. will be affected if they update modplug.

(BTW, this did not happen with SDL_mixer 1.2 because it uses mikmod instead of modplug, and SDL2_mixer is only affected since a few weeks ago because the modplug package was updated in September in Debian -- so the first SDL2 packages, created in July/August, compiled fine).

So, if you confirm me that you prefer to not change things in SDL side at the moment for the aforementioned reasons, which is understandable, I will make sure to get this fixed on the packaging side, no problem.

On 2014-07-03 23:47:20 +0000, Maarten ter Huurne wrote:

Created attachment 1733
Patch to include modplug via "libmodplug/modplug.h"

I think every distro that updates libmodplug to 0.8.8.5 will run into this problem, so I would prefer if SDL_mixer were patched. I attached a patch that fixes the issue for me with SDL2_mixer 2.0.0.

I encountered this problem with both SDL_mixer 1.2.12 and 2.0.0. If 1.2.x is still maintained, I can provide a patch for 1.2.12 as well.

On 2014-07-09 08:13:45 +0000, Sam Lantinga wrote:

Unfortunately this breaks builds using the included libmodplug in the external directory, e.g. Windows, Mac OS X, iOS and Android.

If nobody has a better idea, I'll leave the patch for the modplug include path to the Linux distribution maintainers.

On 2014-08-17 05:48:23 +0000, Sam Lantinga wrote:

Okay, I thought through a good solution, thanks!
https://hg.libsdl.org/SDL_mixer/rev/6a5e6d8d6a35