| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: -fPIC |
| Date: | 2005-09-11 16:33:00 |
| Message-ID: | 5296.1126456380@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hans-Jürgen Schönig | 2005-09-11 16:41:36 | Re: random system table corruption ... |
| Previous Message | Tom Lane | 2005-09-11 16:24:39 | Re: random system table corruption ... |