X11Amp
Introduction (Rajiv Zutshi)
Patch Install
We installed the GNU Image Manipulation Program (GIMP), which is a
program that
closely resembles Adobe's Photoshop on MS Windows. Before installing
the GIMP we first installed
a graphics tool kit (gtk) as directed. We had installed gtk-1.0.6.
The gtk is also required by
x11amp which is a piece of software that allows the user to play audio
files (wav,mp3). To use
x11amp, we needed to use a new version of the gtk, namely gtk-1.1.16.
We decided to install the gtk-1.1.15 and then patch it to get to
gtk-1.1.16.
We were interested in installing x11amp (works like WinAmp on MS Windows) because we wanted to see how to obtain sound from a linux box. In addition it would serve as a means of satisfying the 'patch' installation. The primary audience for x11amp would be the users of our machine (magenta.ils.unc.edu), as it would allow us to perform the remaining installations while listening to music.
Narrative (Adam Fuller, Travis Angle)
The Compiling Instructions for X11Amp said we needed at least version 1.1.12 of the gtk and glib. We downloaded glib-1.1.16, gtk+-1.1.15.tar.gz and patch-gtk+-1.1.15-1.1.16.gz from ftp.gimp.org. We gunzipped and untarred each of them in /usr/local/src, and then did the usual ./configure, make, make install in the glib directory. It compiled without any problems. Next we cd ../gtk+-1.1.15/ and applied the 1.1.15->1.1.16 patch:
patch < patch-gtk+-1.1.15-1.1.16
This is where things got a little funny. It patched the configure and Makefile stuff just fine, but it started spitting up errors when it did the doc files:
can't find file to patch at input line 3177 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |diff -ruN gtk+-1.1.15/docs/gtk-config.1 gtk+-1.1.16/docs/gtk-config.1 |--- gtk+-1.1.15/docs/gtk-config.1 Thu Feb 4 02:55:19 1999 |+++ gtk+-1.1.16/docs/gtk-config.1 Tue Feb 16 12:24:19 1999 -------------------------- File to patch:
We experimented with different levels with the -p, but found we got the best result when we supplied the full pathname to patch instead of a relative pathname or different level of -p or --strip:
File to patch: /usr/local/src/gtk+-1.1.15/docs/gtk-config.1 patching file `/usr/local/src/gtk+-1.1.15/docs/gtk-config.1'
That worked fine until until we got back around to the Makefile and c files:
patching file `Makefile' Hunk #1 FAILED at 29. 1 out of 1 hunk FAILED -- saving rejects to Makefile.rej The next patch would create the file `Makefile', which already exists! Assume -R? [n]
We answered y, just because it seemed to work in a previous run through the patch, and got these results:
patching file `Makefile' Hunk #1 FAILED at 1. File `Makefile' is not empty after patch, as expected. 1 out of 1 hunk FAILED -- saving rejects to Makefile.rej
Then we tried n and then y to the next question:
The next patch would create the file `Makefile', which already exists! Assume -R? [n] n Apply anyway? [n] y patching file `Makefile' Patch attempted to create file `Makefile', which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to Makefile.rej
We were confused, so on the next one, we went straight ns:
The next patch would create the file `fixed.c', which already exists! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 1 out of 1 hunk ignored -- saving rejects to fixed.c.rej
Confusion increased after a couple of files' patches went well:
The next patch would create the file `rangewidgets.c', which already exists! Assume -R? [n] y patching file `rangewidgets.c'
That's when we noticed it would only complain when "The next patch would create the file `Makefile'". With that figured out, our patching went along rather painlessly after that (except for all the damn cutting and pasting).
After all that, we finally got to do make ; make install which took a long time, but went smoothly without a hitch.
We moved on to the x11amp directory. The site itself seemed to be down, but Adam had a copy on his slackware machine in his room. We tarred and gzipped that up and ftped it over. We unpacked it, chdirred into it, and did the magical ./configure ; make ; make install. That took a while to compile, too.
Peruse through our script file to see what went down.
Functionality (Roger Smith)
It doesn't work. We tried running it on tons of other machines, but each time we got the exact same error:
magenta{adam}:/home/users/adam % x11amp
/usr/local/lib/x11amp/Input/libmikmod.so: undefined symbol: ap_signal
We attempted to play a few mp3s that we had lying around the office, but each time we went to play it, it always hacked up an Can't open audio! error. We went down to console, and played around with the /dev files, all to no avail. We had lost all hope, until I realized we hadn't compiled in sound support into the kernel!
We decided that we should recompile the kernel with sound support. But to make it even more interesting, why don't we just upgrade the kernel to 2.2.x? We'll find out next week if x11amp will work after compiling the new kernel.
UPDATE: Once the new kernel was configured properly with sound support, X11amp worked beautifully. The occupants of the SILS lab were treated to a special rendition of the beastie boys' "sabatoge" courtesy of magenta.ils.unc.edu. Unfortunately, network support mysteriously failed. That problem was remedied and will be covered in the kernel write-up.
March 14, 1999
March 18, 1999