Arch Linux

esd is a plugin that can be dlopen()-ed, it's not a dependency.

Thanks JGC. As I mentioned in the thread that I linked to, I'm not having this problem. But as you can see, not having esd is breaking multiple programs from other people, and sdl seems to be the big change. There are at least three people in that thread that are suffering from something related to this.

No, that's because the maintainer of those packages installed esd while building those packages. Some packages can optionally include support for esound. Building these packages while esound isn't installed breaks those packages. As nobody seems to run namcap these days you'll get broken dependencies on those packages.

Kinda strange... all I did in SDL was add --disable-rpath to the PKGBUILD and now:

1.2.13-1
> ldd /usr/lib/libSDL-1.2.so.0
linux-gate.so.1 => (0xb7f56000)
libm.so.6 => /lib/libm.so.6 (0xb7e83000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e7f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e67000)
libc.so.6 => /lib/libc.so.6 (0xb7d25000)
/lib/ld-linux.so.2 (0xb7f57000)

1.2.13-2
> ldd /usr/lib/libSDL-1.2.so.0
linux-gate.so.1 => (0xb7f66000)
libdl.so.2 => /lib/libdl.so.2 (0xb7eb4000)
libesd.so.0 => /usr/lib/libesd.so.0 (0xb7eaa000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb7e85000)
libm.so.6 => /lib/libm.so.6 (0xb7e5f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e46000)
libc.so.6 => /lib/libc.so.6 (0xb7d04000)
/lib/ld-linux.so.2 (0xb7f67000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7c3c000)
librt.so.1 => /lib/librt.so.1 (0xb7c33000)

This was not caused by disabling rpath so I need figure out why this change happened...

Make that (at least) 4 people.

Allan, I interpreted your comment to mean that sdl should still provide libesd. Is that going to be added back in (not sure if it was included in the package or as a dep) or should I go ahead and install esd explicitly?

Thanks.

Eventually tracked this down to a problem in the configure script with esd > 0.2.38...