Re: Packaging a shared library with non-PIC assembly
On Sun, Jul 10, 2005 at 10:25:57PM -0400, Ryan Schultz wrote:
> 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:
ASM for what arch? If its 386 only, then I think a lintian override
is appropriate (could someone confirm this?).
My understanding is that the PIC/nonPIC thing for shared libraries
isn't important on 386 (and the code produced may even be the same,
but one will be marked as "PIC"). For other archs, it is significant,
and non-PIC code will either not work in a shared lib, or will require
a huge number of slow relocations (and at this point I'm speaking over
my head; stopping).
Justin
> 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.
This is consistent with my experience; I don't know if hand-coded asm
can be manually tagged as "PIC", or if the assembler is supposed to be
able to tell, or what. In any case, its probably simply not PIC.
> 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.
As I understand, they're not ideal, but its probably not a huge deal.
I would tend towards the latter; static linking of something that is
dynamic upstream, and including two upstream sourceballs in one
.orig.tar.gz (which I believe is now handled more gravefully by
dpkg-dev). Then you might have a changelog entry of the form:
* Update OpenSPC to 1.2.3.
Cheers,
Justin
Reply to: