Thread: -fpic vs. -fPIC

-fpic vs. -fPIC

From
Peter Eisentraut
Date:
Late in the 7.4 release we've added a patch that changed -fpic to -fPIC
for Linux Sparc.  We wanted to investigate that issue further later on.

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.

Any other suggestions on how to deal with this?

-- 
Peter Eisentraut   peter_e@gmx.net



Re: -fpic vs. -fPIC

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.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?
        regards, tom lane


Re: -fpic vs. -fPIC

From
Lamar Owen
Date:
On Friday 28 November 2003 12:31 pm, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.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@redhat.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



Re: -fpic vs. -fPIC

From
Tom Lane
Date:
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.

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.
        regards, tom lane


Re: -fpic vs. -fPIC

From
Bruce Momjian
Date:
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.
> 
> 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.

One question would be what happens when it fails?  Does it fail visibly
so we would hear about it?  If so, we can take the risk.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: -fpic vs. -fPIC

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The best I have been able to tell is that none of our .so's are anywhere
>> near large enough to require -fPIC.

> One question would be what happens when it fails?  Does it fail visibly
> so we would hear about it?  If so, we can take the risk.

Yes, you'd get a link failure.  On the platforms I've seen it on (HPUX
at least, on an old project with .so's in the dozens-of-megabytes range)
the error message is pretty specific that you should have used -fPIC.
        regards, tom lane


Re: -fpic vs. -fPIC

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> The best I have been able to tell is that none of our .so's are anywhere
> >> near large enough to require -fPIC.
> 
> > One question would be what happens when it fails?  Does it fail visibly
> > so we would hear about it?  If so, we can take the risk.
> 
> Yes, you'd get a link failure.  On the platforms I've seen it on (HPUX
> at least, on an old project with .so's in the dozens-of-megabytes range)
> the error message is pretty specific that you should have used -fPIC.

Great.

In general, I am not sure we are always explicit that taking risks is
contingent on how the user will see a possible failure.  For example, if
-fpic generated SELECT query failures randomly, that would be a much
less attractive risk than a link failure.

Risk is a function of both the probability, and the _visibility_ of the
failure.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: -fpic vs. -fPIC

From
Lamar Owen
Date:
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



Re: -fpic vs. -fPIC

From
Greg Stark
Date:
Lamar Owen <lowen@pari.edu> writes:

> So, no, -fPIC does not appear to be required for libpq.  

My understanding was that at least on some platforms once you need -fPIC for
some libraries you need to make sure they were all compiled with it. That
means it's a pain if any libraries are provided compiled with -fpic because
whenever find one that reaches that threshold they all have to be recompiled.

At least Debian decided long ago to just make everything -fPIC to avoid having
problems later. I don't know what the convention is on other OS's though.

-- 
greg



Re: -fpic vs. -fPIC

From
Peter Eisentraut
Date:
Greg Stark writes:

> My understanding was that at least on some platforms once you need -fPIC for
> some libraries you need to make sure they were all compiled with it. That
> means it's a pain if any libraries are provided compiled with -fpic because
> whenever find one that reaches that threshold they all have to be recompiled.

Considering that mostly everyone else uses -fPIC across the board (because
it is libtool's behavior and also the policy of several distributions),
either no one has used PostgreSQL on those platforms or there is no
problem.

-- 
Peter Eisentraut   peter_e@gmx.net