non-PIC libraries

Bug #919509 reported by Jamie Strandboge on 2012-01-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
x264 (Debian)
Fix Released
Unknown
x264 (Ubuntu)
Low
Unassigned

Bug Description

$ lintian x264_0.120.2127+gitf33c8cb-2ubuntu2_i386.changes:
E: libx264-120: shlib-with-non-pic-code usr/lib/i386-linux-gnu/i686/sse2/libx264.so.120
E: libx264-120: shlib-with-non-pic-code usr/lib/i386-linux-gnu/libx264.so.120

On Sa, Jan 21, 2012 at 04:38:32 (CET), Jamie Strandboge wrote:

> Public bug reported:
>
> $ lintian x264_0.120.2127+gitf33c8cb-2ubuntu2_i386.changes:
> E: libx264-120: shlib-with-non-pic-code usr/lib/i386-linux-gnu/i686/sse2/libx264.so.120
> E: libx264-120: shlib-with-non-pic-code usr/lib/i386-linux-gnu/libx264.so.120

What is the problem with those?

Note that x264 uses a *lot* of hand written assembler, and carefully
uses non-pic code only on architecture where possible.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Changed in x264 (Ubuntu):
status: New → Incomplete
Jamie Strandboge (jdstrand) wrote :

From http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-files.html#s10.2:
"If the package is architecture: any, then the shared library compilation and linking flags must have -fPIC, or the package shall not build on some of the supported architectures[64]. Any exception to this rule must be discussed on the mailing list <email address hidden>, and a rough consensus obtained. The reasons for not compiling with -fPIC flag must be recorded in the file README.Debian, and care must be taken to either restrict the architecture or arrange for -fPIC to be used on architectures where it is required.[65]
...

[65]Some of the reasons why this might be required is if the library contains hand crafted assembly code that is not relocatable, the speed penalty is excessive for compute intensive libs, and similar reasons. "

Based on your feedback, it sounds like the exception is ok, but it should be brought up on the mailing list (since this is in Debian, debian-devel would be fine), then the README.Debian file updated to explain why non-PIC and then a lintian override applied.

Changed in x264 (Ubuntu):
status: Incomplete → Triaged

Package: x264
Version: 2:0.116.2042+git178455c-1
Severity: wishlist

Bug forwarded from https://bugs.launchpad.net/bugs/919509

Seems that according to Policy §10.2, we need to document why we are not
building the shared library with -fPIC in the file README.Debian and get
consensus on that on the debian-devel mailing list.

The reason is that x264 uses a lot of hand written assembler, and
upstream takes care to use non-pic code only on architectures that
support this.

Btw, the same applies to the libav* packages.

Cheers,
Reinhard

Changed in x264 (Ubuntu):
importance: Undecided → Low
Changed in x264 (Debian):
status: Unknown → New
Changed in x264 (Debian):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package x264 - 2:0.120.2151+gita3f4407-2

---------------
x264 (2:0.120.2151+gita3f4407-2) experimental; urgency=low

  [ Fabian Greffrath ]
  * Meanwhile, upstream enabled PIC for the shared library build on ia64,
    mips* and hppa/parisc (once more closes: #642810), so remove our
    Debian-specific workarounds.

  [ Reinhard Tartler ]
  * Build against libgpac to enable MP4 output
  * Add a note about non-relocatable code in the README.Debian file,
    Closes: #657019, LP: #919509

 -- Reinhard Tartler <email address hidden> Fri, 10 Feb 2012 21:26:18 +0100

Changed in x264 (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.