Обсуждение: -fpic vs. -fPIC
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
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
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
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
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
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
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
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
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
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