This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Dri-devel] Re: OpenGL and the LinuxThreads pthread_descr structure


David S. Miller wrote:
>    
> Why does it matter?  Jakub has shown how to get the same kind of
> non-PIC relocations you want in the GL libraries by using private
> versions of symbols.

Using a feature that is "a very new thing" (to quote Jakub) -- only "GCC 
3.2 (mainline CVS), the Red Hat GCC 3.1 package and gcc-2.96-RH >= 
2.96-108" support this.

> Also, the PIC register argument is bogus too.  I know for a fact that
> current GCC will fully allow allocation of the x86 PIC register
> if you make no references to PIC relocatable data.  %99 of functions
> in an OpenGL implementation will get full use of the PIC register,
> _ESPECIALLY_ if you use the privatization symbol tricks Jakub
> mentioned.
> 
> It should be rare to reference PIC symbols from within OpenGL if done
> properly, thus the PIC register and the relocation arguments are null
> and void.

That may be so, using a bleeding-edge version of GCC, but you haven't 
answered my question.  Besides, moving a workstation-quality OpenGL 
driver to a new compiler like this, just to avoid the penalties 
associated with -fPIC, is not something done lightly.  I know for a fact 
that versions of gcc-2.96-RH have produced a non-functional driver for 
me in the past (missing triangles while running Viewperf, etc).

-- Gareth


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]