Bug 89241 - media-libs/sdl-sound can use libmodplug when available
|
Bug#:
89241
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: games@gentoo.org
|
Reported By: tsm@accesscomm.ca
|
|
Component: Library
|
|
|
URL:
|
|
Summary: media-libs/sdl-sound can use libmodplug when available
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-04-15 17:54 0000
|
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
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