Bug#175074: Bug#175077: libdv2: libraries not compiled with -fPIC
On Fri, Jan 10, 2003 at 02:13:56AM +0100, Marco d'Itri wrote:
> On Jan 10, Jakub Jelinek <jakub@redhat.com> wrote:
>
> >Normally libGL in XFree86 is compiled without -fPIC (I have a patch to
> >change that, but need to update it and test whether libGL is at least as
> >fast as before).
> >If you made sure all libGL.so .c files are compiled with -fpic/-fPIC and
> >the library is still DT_TEXTREL, you might as well look at assembly files.
> >Easiest is just watching what relocations are against the read-only segment
> >on the final library.
> I tried building libdv2 without the x86 hand-written assembly and
> DT_TEXTREL disappeared, so I think the problem is there. Do you have any
> suggestion I could pass upstream to have it fixed?
I had been looking for rel(a).text sections instead of TEXTREL (which is
also what lintian checks for--I wonder whether that's a bug or on
purpose). Now I remember in the past libdv would not build as a shared
lib at all, precisely because of non-PIC issues in the hand-crafted
assembly. Upstream at the time preferred building static-only to
wasting a register on the GOT pointer. libdv works fine as a shared lib
now, so I assumed the issue had been fixed in the meantime.
(Looking at the prelink sources, I noted that it tries to prelink even
non-PIC libs if there's no overlap. 0.98-2 contained a bug that would
link libdv against a number of unneeded libs, cluttering address space.
It's fixed in 0.98-4, which I guess is the reason why I can prelink in
unstable while it fails for you in testing.)
> I could not rebuild X, but I have seen that libGL has x86 assembly code
> too and the maintainer verified that it's not DT_TEXTREL on a different
> architecture, so I assume it has the same problem. I looked at the red
> hat XFree86 SRPM but could not find any patch related to prelinking or
> libGL, how did you fix this?
I'd like to put this up for discussion on debian-policy. Note that
policy does not talk about position-independent code. Instead, it
specifically mentions -fPIC, which does not apply to assembly. The
question is whether we want to potentially decrease performance of
hand-crafted assembly for the benefit of faster program startup?
Regards,
Daniel.
Reply to: