-fPIC
Peter Eisentraut
until we have received some sort of overflow that forced the use of
-fPIC. Since 8.0, the makefiles to build shared libraries are also
available to external modules through the pgxs system, so we cannot
exactly check anymore what the fpic vs. fPIC requirement of each
conceivable module is. I have just received confirmation that PL/Java
needs -fPIC to compile on Alpha and S/390 on Linux, so we need to make
at least that change, but maybe it's more prudent to change to -fPIC
across the board now. Comments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Tom Lane
> So far, we have tended to use -fpic to compile position-independent code
> until we have received some sort of overflow that forced the use of
> -fPIC. Since 8.0, the makefiles to build shared libraries are also
> available to external modules through the pgxs system, so we cannot
> exactly check anymore what the fpic vs. fPIC requirement of each
> conceivable module is. I have just received confirmation that PL/Java
> needs -fPIC to compile on Alpha and S/390 on Linux, so we need to make
> at least that change, but maybe it's more prudent to change to -fPIC
> across the board now. Comments?
PL/Java is bigger than the whole backend?
The reason for -fpic vs -fPIC (on the machines where it makes any
difference at all) is that the former is faster. I'm not real thrilled
by the prospect that a bloated add-on should get to dictate an
across-the-board slowdown even on installations where it will never
be used.
I think the correct answer is for PL/Java to do s/-fpic/-fPIC/ on
CFLAGS in its Makefile, rather than trying to force the same on
everything else.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Peter Eisentraut
> PL/Java is bigger than the whole backend?
No, it's not, but the backend is not compiled as position-independent.
> The reason for -fpic vs -fPIC (on the machines where it makes any
> difference at all) is that the former is faster.
I don't doubt that, but out of curiosity, considering that everyone else
is using libtool, and libtool always uses -fPIC, what kind of impact
does this *really* have?
> I think the correct answer is for PL/Java to do s/-fpic/-fPIC/ on
> CFLAGS in its Makefile, rather than trying to force the same on
> everything else.
That would certainly work, but is that the kind of interface we want to
offer? In the extreme case, a module could end up redefining a great
deal of the shared library knowledge that it was supposed to not have
to care about.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
Kurt Roeckx
> So far, we have tended to use -fpic to compile position-independent code
> until we have received some sort of overflow that forced the use of
> -fPIC. Since 8.0, the makefiles to build shared libraries are also
> available to external modules through the pgxs system, so we cannot
> exactly check anymore what the fpic vs. fPIC requirement of each
> conceivable module is. I have just received confirmation that PL/Java
> needs -fPIC to compile on Alpha and S/390 on Linux, so we need to make
> at least that change, but maybe it's more prudent to change to -fPIC
> across the board now. Comments?
Can we avoid those relocation by not exporting variables and
function that shouldn't be exported and marking them static? Or
is static already being used properly?
Kurt
Stephen Frost
> Tom Lane wrote:
> > The reason for -fpic vs -fPIC (on the machines where it makes any
> > difference at all) is that the former is faster.
>
> I don't doubt that, but out of curiosity, considering that everyone else
> is using libtool, and libtool always uses -fPIC, what kind of impact
> does this *really* have?
I certainly wouldn't assume something done in libtool is necessairly the
'smart' approach, ever.
> > I think the correct answer is for PL/Java to do s/-fpic/-fPIC/ on
> > CFLAGS in its Makefile, rather than trying to force the same on
> > everything else.
>
> That would certainly work, but is that the kind of interface we want to
> offer? In the extreme case, a module could end up redefining a great
> deal of the shared library knowledge that it was supposed to not have
> to care about.
I don't think it's all that sane to expect a generalized build system to
support every possible library compilation requirement...
Thanks,
Stephen
Greg Stark
> > The reason for -fpic vs -fPIC (on the machines where it makes any
> > difference at all) is that the former is faster.
>
> I don't doubt that, but out of curiosity, considering that everyone else
> is using libtool, and libtool always uses -fPIC, what kind of impact
> does this *really* have?
Incidentally, Debian uses -fPIC as a matter of policy everywhere too. I think
the problem is that it's hard to know in advance whether -fpic is going to
cause a problem and mixing -fpic and -fPIC libraries is a problem. So it's
safer to just compile all the libraries with -fPIC.
--
greg
Tom Lane
> ... mixing -fpic and -fPIC libraries is a problem.
Is it? I would think having two options would be essentially unworkable
if so.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Martijn van Oosterhout
> Greg Stark <gss...@mit.edu> writes:
> > ... mixing -fpic and -fPIC libraries is a problem.
>
> Is it? I would think having two options would be essentially unworkable
> if so.
The thing is, on i386 it makes no difference, it's only on some
archtechtures where it matters. And it has to do with both the size of
the symbol table and the size of the code.
Given that you don't know what you need to use until you compile it, if
people are compiling all their stuff with -fPIC you can at least be
sure that it won't break on other architectures.
The new gcc visibility stuff gives you way of shrinking the symbol
table and improving performance. There is a performance difference
between -fpic and -fPIC, whether it's big enough to care about...
You can shrink the symbol table with --version-script in LD, you
provide a script like:
{
global:
pg_finfo_*
<other exported symbols>
local: *
}
Whether it's enough... For people who want to know the gory details,
read this (by Ulrich Drepper).
http://people.redhat.com/drepper/dsohowto.pdf
--
Martijn van Oosterhout <kle...@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
Kurt Roeckx
>
> The new gcc visibility stuff gives you way of shrinking the symbol
> table and improving performance.
And you really should start with making use of static, which has
about the same effect, except that the visibility stuff works
accross compile units.
> You can shrink the symbol table with --version-script in LD, you
> provide a script like:
>
> {
> global:
> pg_finfo_*
> <other exported symbols>
> local: *
> }
And if you use the visibility stuff properly, it should end up
with only exporting the same symbols you put in the version
script. However, the version script is good other things too.
Those are all things you should consider doing, but only one of
them is really portable, and that is making use of static where
you can.
> Whether it's enough... For people who want to know the gory details,
> read this (by Ulrich Drepper).
>
> http://people.redhat.com/drepper/dsohowto.pdf
And it's good reading, everybody making a shared object really
should read this.
Kurt