This is absurd. Debian policy explicitly states that you should not create a shared lib using objects not created with -fPIC (which is exactly what libsdl-image does when it asks sdl-config what to use for static_x_extension_libs). This problem is identical to one just resolved in evolution...
evolution (1.0-2) unstable; urgency=low * Applied fPIC patch of Bug#124141 (closes: #124141) * Applied correcthelosmtp.diff of Bug#123922 (closes: #123922) * debian/control: - remove beta notice from Description. ...where libcamellocal.so was being built using a static lib libebex built without using -fPIC. This was WRONG! One of the problems with this Debian policy violation is that it is not always reproducible as a bug on other folks machines. However feel free to ask on debian-powerpc and the will confirm that it is in fact wrong to use non-fPIC static libs in a shared lib on ppc and in fact any arch under Debian. Branden seems to have gone off the deep end here. All I am trying to do is eliminate a serious policy violation in libsdl. Either sdl-config is modified to be bright enough to return a different answer for static_x_extension_libs... static_x_extension_libs="-lXxf86dga_pic -lXxf86vm_pic -lXv_pic" if a shared lib is being built or sdl-config has to always assume a shared lib might be built and do the same. Again, I'm just reporting a real bug in these packages that impacts Debian ppc sid (and probably other arches). Don't flame me just because you don't want to hear a real problem. Jack ps I can't be held for treason in the UK. We bailed out of that joint almost 100 years ago.