Re: gcc 3.2.2

[Reuben Thomas <rrt@...>]

> Sometimes you get away with it on x86, other times (especially if you
> start using the more arcane bits of C such at setjmp, longjmp etc) you
> encounter issues where different code entirely is needed for PIC vs
> non-PIC usage.
>
> You should *never* compile a shared object non-PIC unless you are very
> very very sure that you know what you are doing, and that you understand
> how to force the shared object into a very specific part of the address
> space of the target program (and that you can thusly link it into the
> right virtual addresses).

Oh great, so unlike the wonderful world of ARM where PIC is the only
option, on x86 you get the option to shoot yourself all because you might
otherwise lose a few % performance. Sigh. I wouldn't have any problem
being able to turn PIC off, but it should at least be the default.

> I had to retrofit a set of build rules onto the Lua makefiles to build
> shared objects properly.

I'm only really worried about x86, as I'm not maintaining my package for
Fedora Core or anything fancy. Are there architectures on which building
-fPIC for shared objects is a problem?

> So in summary -- when building a shared object *always* compile -fPIC
> (-fpic) and *always* link -fPIC too. Regardless of the target
> CPU/code-generator, both the compiler and linker need to know that
> they're meant to be making code for a shared object.

Ah, the linking I hadn't cottoned on about. I'll shuffle off and do that
now; if anyone's reading this who read my earlier announcement of an
update, then look for the -2 release of the RPM, which will be built with
-fPIC for linking too. I won't bother to reannounce.

-- 
http://www.mupsych.org/~rrt/ | Caution Children At Play Drive Slowly (Anon)