Re: gcc 3.2.2

[Daniel Silverstone <dsilvers@...>]

On Tue, 2003-12-02 at 17:35, Reuben Thomas wrote:
> Running the tests that caused segfaults before now seem to meet with
> success, although the cause might also be that I'm now using GCC 3.3
> rather than 3.2. In any case, not using -fPIC or -fpic shouldn't cause
> problems of this sort, it should just make the program slower and/or
> bigger; at least that's my understanding (on x86).

The compiler flag -fPIC (-fpic) tells the compiler (and linker) to
create position independant code. On many CPUs the default code
generators actually create position independant code. On some systems
this then works as a shared object. In many cases this isn't the
situation.

On x86, the issue you are encountering is to do with the differences
between PIC code, PIC pre/postamble on functions, PIC library interfaces
and PIC dynamic trampolines. Theoretically you'd see no problems at all
on ARM, and on SPARC, MIPS etc, your code would explode impressively the
moment you tried to use a non PIC shared object.

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).

In general, it is the job of the software packager to ensure that their
package is as portable as their target audience would expect. In your
case that means as many platforms as the Fedora core expects to target.
In my case that's over 11 platforms (Debian is widely ported). This
means that we really need to be sure about what PIC vs non-PIC means for
our users. I had to retrofit a set of build rules onto the Lua makefiles
to build shared objects properly.

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.

Regards,

Daniel

-- 
Daniel Silverstone <dsilvers@digital-scurf.org>
Digital-Scurf