amd64 and -fPIC

Marcel Moolenaar marcel at
Tue Mar 7 20:54:59 UTC 2006

On Tue, Mar 07, 2006 at 08:58:49PM +0100, pfgshield-freebsd at wrote:
> An honest question: I would like to know what other modern architectures
> require this, I heard (but I'm not sure) that it's a consequence of the
> architecture running both 64 and 32 bit code so.. SPARC64 and ia64 need it too?

Yes, ia64 has the same link constraints. I don't think sparc64 has
the same problems, but that doesn't mean anything. A shared object
has to be position independent and any object files that constitute
the shared object have to be constructed in such a way. For C/C++
and GCC this means that -fPIC is required. Some platforms (i.e. i386)
don't generate different code for -fPIC, so the omission of -fPIC
when it is necessary doesn't result in problems. This is just a
quirk of the platform, not the norm. Also, linking an archive library
into a shared object is perfectly valid, provided of course that all
object files in the archive library are compiled for inclusion in a
shared object. This of course means that they must be position
independent and thus compiled with -fPIC (or equivalent). As such,
you must determine up front for what purpose you create an archive
library (linking into an executable or linking into a shared object)
or create 2 variants: one non-PIC and one PIC.

A generic port that only builds archive libraries better be PIC to
cover all bases. Performance cannot really be a concern when you're
working with generic parts. If performance is a concern, customization
is pretty much a given and the use of generic parts is almost always

The kicker:
	With the introduction of the __thread keyword to define
thread local storage, i386 now also requires the correct use of
-fPIC, because the code generated for thread local storage is
different for PIC and non-PIC. As far as I know, *NO* architecture
can link shared objects without proper use of -fPIC when thread
local storage is to be considered. Beware!!!!!

 Marcel Moolenaar	  USPA: A-39004		 marcel at

More information about the freebsd-ports mailing list