Re: -fpic vs. -fPIC

On Friday 28 November 2003 12:31 pm, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
> > So I suggest that we change back to -fpic until we get detailed evidence.

> Okay with me. It never struck me that we'd really seen adequate
> evidence that -fPIC was needed.

> Makefile.solaris is the only other place where gcc -fPIC is selected;
> should it be changed also?

If it is in Makefile.solaris, we would need to think about it, IMO. -fpic is
not guaranteed to work properly on SPARC; -fPIC is. There was a reason it
was put in Makefile.solaris, I'm sure. Tracing its lineage shows it was in
the very first template for Solaris.

The project lead for the Aurora SPARC Linux project is who recommended it in
the first place; lessee, the last word we had on the subject was from Jakub:
>On Wed, May 21, 2003 at 10:15:19AM -0400, Tom Lane wrote:
>> Jakub Jelinek <jakub(at)redhat(dot)com> writes:
>> > readelf -WS thelibrary.so | sed -n 's/^.* \.got.*PROGBITS//p' | awk '{
>print $3 }'
>> > If the printed number is bigger than 0x2000, you need -fPIC, otherwise
you
>> > should use -fpic.
>>
>> Ah-hah. And I would imagine that this number depends only on the number
>> of global symbols used in the library, and therefore will be the same on
>> every arch?
>
>Nope, it may differ accross arches (and not only because 32-bit vs. 64-bit,
>but on SPARC e.g. because there is no GOT relative relocation, so even
>static int i; int *foo (void) { return &i; } needs to allocate a .got slot
>for i.
>
> Jakub

So, just because -fpic could work now is meaningless. It could break silently
in the future, for random .so's. It would depend on the specific .so; get
one that's large enough and you break. It is SOP for the Aurora Linux
distribution to use -fPIC for all .so builds, IIRC. But testing of the GOT
size would be needed on a .so by .so basis to make sure that everything
worked. And it might work for one compiler version and not another; Aurora
Linux currently is built with gcc 2.96, but the move is afoot to go to gcc 3
and be Fedora Core based.

So, I ask, why change something that is going to work every time to something
that may very well break silently in the future? (yes, I know about the
performance difference; is the increased performance worth the tradeoff?)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu