Bug#493705: libswscale0: The library has text relocations
lool at dooz.org
Mon Aug 4 12:59:19 UTC 2008
On Mon, Aug 04, 2008, Russell Coker wrote:
> The references you provide seem to indicate that the exception is for
> the case where faster assembly is not available. IE you have a choice
> between fast assembly and a slower compiled language. While if the
> difference is only 10% (between two different versions of assembly
> code) then PIC is the way to go.
Based on my memory of the discussions, it seemed to me that there is a
performance hit in all cases if you use PIC instead of non-PIC on i386
because a register is used for the relocations; I think this impacts
both assembly and compiled languages, however I could imagine cases
where custom assembly wont build at all if PIC is used (as it might
require more registers than PIC mode provide).
> I expected that the probability of you including my patch to disable the
> assembler was low (although a similar patch is in the Fedora tree for
> libtheora), but if nothing else it clearly illustrates where the problem is
> for anyone who wants to have a go at writing some assembler.
Well, it's interesting to note that Fedora favors SELINUX support
before speed; perhaps something you can bring up in a wider discussion
of this policy decision.
> > I see two ways to go forward: implement a way to disable execution of
> > such binaries when under SELINUX, or force usage of -fPIC, even in
> > performance critical code.
> If the performance critical code is going to be handling data from sources of
> low integrity (EG playing video downloaded from youtube etc) then I think
> that we want all the available security features enabled!
I'm not sure I agree with the rationale; certainly having SELINUX
properly working in apps playing remote contents is a laudable goal,
but I understand SELINUX doesn't make any difference if the libs are
secure already, and we do want the libs to be secure. However
performance is useful in all cases. So I still think it's a compromise
which needs wider consensus.
> But having library A try and load library B at runtime and then load
> library C if B fails (where B is the non-PIC version and C is the PIC
> version) would be a viable option.
Definitely. Some multimedia frameworks such as GStreamer are perfectly
capable of doing this if you offer two versions of the same plugin with
different ranks -- the ones failing to load simply aren't added to the
registry of available plugins.
More information about the pkg-multimedia-maintainers