On Fri, Jan 10, 2003 at 02:13:56AM +0100, Marco d'Itri wrote: > On Jan 10, Jakub Jelinek <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
