I'm trying to package libopenspc, so that I can correctly build the CVS (0.0.4) release of xmms-openspc (upstream said to mark it as 0.0.4 because there won't be anymore changes), to package it, and I've encountered what seems to be a showstopper.
libopenspc is used for playing Super Nintendo sound files (SPCs) and the core that does the decoding is written in assembly and compiled with NASM, then built into the rest of the C that forms the shared lib. The problem is, the emulator core isn't written to be position independent, so once everything is done, I get the following error from lintian: E: libopenspc0: shlib-with-non-pic-code usr/lib/libopenspc.so.0 I've tried building everything else with -fPIC and checked the other suggestions of Lintian, and I'm almost certain that it is the assembly which is causing this error. Rewriting the SNES SPC700 audio core ASM code to be position independent would appear to be... non-trivial, to say the least :- ) Can I just use a lintian override? That doesn't seem like a very good solution, and it's definitely not policy compliant -- the .so that is created does function properly though, as far as I can tell. My only other solutions are to either backport the CVS changes to the 0.0.3 version of xmms-openspc, which statically links OpenSPC, or to rewrite 0.0.4 to statically link (which means I have to put OpenSPC code into the xmms-openspc package that isn't there upstream, making a huge mess) -- neither of these are ideal solutions. Though I wouldn't complain too much about forgetting libopenspc, blasted unmaintained, Makefile built, no SONAME/libtool mess that it is... Any assistance you can give me will be greatly appreciated; if there's nothing I can do without rewriting the core to be PIC, I'm going to go ahead and try to rewrite the 0.0.4 makefiles to statically link, and then send that upstream, hopefully to be the official 0.0.4 release. -- Ryan Schultz -> floating point exception: divide by cucumber
pgpx2ZAALi0wE.pgp
Description: PGP signature
