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?

Search Discussions

  • Tom Lane at Sep 11, 2005 at 4:33 pm

    Peter Eisentraut writes:
    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
  • Peter Eisentraut at Sep 11, 2005 at 5:11 pm

    Tom Lane wrote:
    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.
  • Stephen Frost at Sep 11, 2005 at 8:56 pm

    * Peter Eisentraut (peter_e@gmx.net) wrote:
    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 at Sep 12, 2005 at 1:21 am

    Peter Eisentraut writes:

    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 at Sep 12, 2005 at 2:32 am

    Greg Stark writes:
    ... 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
  • Martijn van Oosterhout at Sep 12, 2005 at 7:06 am

    On Sun, Sep 11, 2005 at 10:32:51PM -0400, Tom Lane wrote:
    Greg Stark <gsstark@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 <kleptog@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 at Sep 12, 2005 at 5:29 pm

    On Mon, Sep 12, 2005 at 09:06:03AM +0200, Martijn van Oosterhout wrote:

    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
  • Kurt Roeckx at Sep 11, 2005 at 6:49 pm

    On Sun, Sep 11, 2005 at 05:49:40PM +0200, Peter Eisentraut wrote:
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 11, '05 at 3:49p
activeSep 12, '05 at 5:29p
posts9
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase