now that libmodplug's been seperated out into it's own library, sdl-sound ought to be able to check for and compile in support for it, and I'm happy that it can since modplug is higher-quality and much stabler that mikmod. This turned out to be slightly easier said than done, since it expects modplug.h under /usr/include instead of /usr/include/libmodplug, but a patch for configure.in and some flagomatic magic convinced it to work. I'll attach these. Reproducible: Always Steps to Reproduce: 1. emerge libmodplug 2. tar -zxf SDL_sound-1.0.1.tar.gz ; cd SDL_sound-1.0.1 2. patch < ../gcc311.patch 3. patch < ../libmodplug.patch 4. ./configure --with-modplug ... 5. make, etc Actual Results: sdl-sound compiled with working libmodplug support. Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r0, 2.6.5 x86_64) ================================================================= System uname: 2.6.5 x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System version 1.6.10 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4 [2.3.4 (#1,Jun 29 2004, 09:40:45)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.2.3-r5, 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -m64 -mmmx -momit-leaf-frame-pointer -fomit-frame-pointer -pipe -ffast-math -fmerge-all-constants" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -m64 -mmmx -momit-leaf-frame-pointer -fomit-frame-pointer -pipe -ffast-math -fmerge-all-constants" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://ftp.ndlug.nd.edu/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/var/backup" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aalib acpi alsa arts berkdb bitmap-fonts cdr crypt cups curl dga dvd esd fam flac font-server foomaticdb fortran gdbm ggi gif gpm gtk guile imagemagick imlib innodb ipv6 java jp2 jpeg kde libwww lzw lzw-tiff mad mikmod motif mp3 mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl png ppds python qt readline scanner sdl slang speex ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales xml xml2 xmms xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Created attachment 56391 [details, diff] patch for configure.in Tells configure.in to look for modplug.h in /usr/include/libmodplug/
Created attachment 56392 [details] sdl-sound-1.0.1-r2.ebuild Modified ebuild to add support for libmodplug to sdl-sound
did you write this patch ? if so, has it been sent upstream ?
Yes, I wrote this patch. I didn't send upstream since I figured gentoo installing modplug.h in a nonstandard location caused it; but now I see that is not the case. I'll send it, but please don't mark this as upstream when we can fix this here; I don't think another release of SDL_sound 1.x is likely when the SDL_sound devs are occupied working on the 2.0 interface, slated for release sometime in the next 30 years. :p
i'll add it to our ebuild if upstream likes it ... sometimes sending patches upstream results in a completely diff way from solving the solution and i prefer to add the final result rather than a bunch of intermediates :p also, i think it'd be better if the configure check would work with either mod package
> i think it'd be better if the configure check would work with either > mod package It can, I had to build it with USE="-mikmod" to exclude it. It's possible for SDL_sound to have *both* linked in, though I don't know which one it defaults to.
No reply from upstream, their changelog hasn't changed in 2 years, and their current plans are for(in the distant future) an entirely new 2.0 API rather than changes to 1.0. In light of that, why not fix it in portage?
mabye ... but the current posted patch isnt acceptable
Your objection is that you'd like it to work with either mod package, yes? It *does*. It even works with both: libstdc++.so.6 => //usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/libstdc++.so.6 (0x00002aaaaabf4000) libc.so.6 => /lib/tls/libc.so.6 (0x00002aaaaae09000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002aaaab02f000) libggi.so.2 => /usr/lib64/libggi.so.2 (0x00002aaaab141000) libgii.so.0 => /usr/lib64/libgii.so.0 (0x00002aaaab24d000) libgg.so.0 => /usr/lib64/libgg.so.0 (0x00002aaaab355000) libaa.so.1 => /usr/lib64/libaa.so.1 (0x00002aaaab45c000) libslang.so.1 => /usr/lib64/libslang.so.1 (0x00002aaaab57b000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002aaaab70d000) libFLAC.so.7 => /usr/lib64/libFLAC.so.7 (0x00002aaaab8ef000) libsmpeg-0.4.so.0 => /usr/lib64/libsmpeg-0.4.so.0 (0x00002aaaaba27000) libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x00002aaaabba1000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00002aaaabd0c000) libmikmod.so.2 => /usr/lib64/libmikmod.so.2 (0x00002aaaabe21000) libdl.so.2 => /lib/libdl.so.2 (0x00002aaaabf6c000) libm.so.6 => /lib/tls/libm.so.6 (0x00002aaaac070000) libmodplug.so.0 => /usr/lib64/libmodplug.so.0 (0x00002aaaac1f6000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/libgcc_s.so.1 (0x00002aaaac353000) /lib64/ld-linux-x86-64.so.2 (0x0000555555555000) It didn't use mikmod when I built it last time, because I told it not to use mikmod via USE flags on the commandline.
sorry, i thought your patch did something it didnt added to 1.0.1-r2
