On Saturday 29 November 2003 01:07 pm, Tom Lane wrote:
> Lamar Owen <lowen@pari.edu> writes:
> > The project lead for the Aurora SPARC Linux project is who recommended it
> > in the first place;
> We were told equally positively, by equally well-informed persons, that
> we should prefer -fpic if at all possible.
And the why is?
> The best I have been able to tell is that none of our .so's are anywhere
> near large enough to require -fPIC. In the absence of any evidence that
> we really are near the threshold, I'd prefer to go for the
> better-performing alternative.
Ok. As I don't have a SPARC running a gcc 3 built distribution, I can't
really check. When the next version of Aurora comes up, we may have some
data points. Until then I can only take Tom Callaway's word for it. He'll
probably patch it out anyway for the Aurora distribution, so it'll only
impact from-source builds anyway.
On my Aurora 1.0 box, the number (given by the line Jakub mentioned) is
0x000560 for libpq.so.3.1, so we're not up there yet. On my Fedora Core
Intel box, libpq.so.3.1 has the number 0x000414, so the SPARC version does
require a larger GOT. This is on Aurora 1.0, though, which is built with gcc
2.96.
So, no, -fPIC does not appear to be required for libpq. OTOH, plpython is
getting closer, with 0x001B70 being printed (0x002000 being the threshold).
On Intel, plpython gets a 0x000E08. So on SPARC plpython at least has a much
larger GOT. And the size of the library is no indication at all as to how
big the GOT is. PL/Python appears to have by a large margin the largest GOT
of the shared objects we ship. If the error is noticeable with -fpic in
place, then it seems to be ok to do this.
Command line to find out:
readelf -WS $SONAME | sed -n 's/^.* \.got.*PROGBITS//p' | awk '{ print $3 }'
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu