I'm getting complaints about the lack of a pixmaps/Makefile.in. And @XMMS_CFLAGS@ is still turning up in src/Makefile even though it doesn't detect XMMS.

The XMMS stuff should be ok (unless it's breaking compilation).

Makefile.in should be autogenerated by running ./autogen.sh in the toplevel loserjabber dir.

Damn, I hate autoconf/automake. 90% of the problems people have with LoserJabber are caused by (my misunderstanding of) those utilities.

The XMMS stuff does actually break compilation, but it's not a big deal; I just have to go in an take it out of the Makefile, otherwise this happens:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/lib/glib/include -I/usr/local/include @XMMS_CFLAGS@ -Wall -g -c history.c
gcc: @XMMS_CFLAGS@: No such file or directory

May not be worth worrying about since I seem to be the only person in the universe to have this happen.

It seems to me that it shouldn't detect xmms if you don't have it installed.

Do you have a program called "xmms-config" on your system? If you don't have xmms, you shouldn't.

Ah, never mind, it works; I had screwed up my configure.in a long time ago and forgotten about it. Everything looks okay to me.

I haven't had any XMMS problems since you fixed the lib problem. getting the current commit to give it a run through now.

no problems. hooray!

I'm not getting an [XMMS] button when I select the music metadata option, even though XMMS was detected properly when I ran configure. I haven't pulled down a new CVS version in quite a while...has something changed that I'm not aware of?

./autogen.sh
./configure --prefix=/usr2
make -j 2
su
make install

I've tried adding the --with-xmms-prefix and --with-xmms-exec-prefix options, but still no button. Probably something really simple I'm overlooking...

One of the major changes is that it dynamically loads the XMMS library at runtime. (This is to make it so binary packages will run on systems that don't have XMMS...)

LoserJabber tries to load a file "libxmms.so", which should be in your library path.
Could you see if you have that file, in either /usr/lib or /usr/local/lib (or wherever libraries go on your system)?

Yeah, that was the problem. Placing a symbolic link to the library in /usr/lib fixed it.

Where was the actual library?
The dlopen() man page says it looks in:
- A colon-separated list of directories in the user's LD_LIBRARY_PATH environment variable.
- The list of libraries cached in /etc/ld.so.cache.
- /usr/lib, followed by /lib.

Did the XMMS support ever work for you previously? I can't imagine ld.so was able to find your XMMS libs before I made the switch.
(I believe ld.so.cache is generated from /etc/ld.so.conf.)

It's really important to me that this works on all systems on the first try. :)

The library was in /usr2/lib. I should have added this to my LD_LIBRARY_PATH, but I didn't. The XMMS support worked just fine before because xmms-config gave configure the location of the library when it was compiled in. But at runtime xmms-config isn't used, so the .so wasn't found then.