The problem actually extends back through the entire dependency chain as well as forward.  Basically any code that you want to be part of a shared library needs to be built with -fPIC as well.  So even if you're not building any vxl shared libraries and leaving them all static, in order for the static vxl libraries to be linked into future shared libraries as dependencies, they must be built with -fPIC.  From a usability standpoint this may lead one to want to always build with -fPIC.  On x64 there is very little penalty for this since there are a few additional instructions in the instruction set that assist in the position independent code (PIC) activities.  The resulting code will often only be one or two additional instructions rather than without -fPIC.  On x86, however, these additional instructions are not available and the compiler will often generate an additional branch to retrieve the necessary information needed for the PIC.  I don't know how this translates though to other architectures.  I definitely think it should be used with a bit of caution and remain as an "opt in" sort of option instead of an "opt out".  But that's just my 2 cents.

Chuck Atkins
R&D Engineer
Kitware, Inc.

-- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos

On Mon, Mar 8, 2010 at 3:47 PM, Matt Leotta <> wrote:
Wheeler, Frederick W (GE, Research) wrote:
> I get a build error like this about four times building 1.14b1:
> Linking CXX shared module ../../../../lib/
> /usr/bin/ld:
> ../../../../lib/libvil_io.a(vil_io_smart_ptr+vil_memory_chunk-.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when
> making a shared object; recompile with -fPIC
> ../../../../lib/libvil_io.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> This exact same error, and others like it are seen on this dashboard
> build:
> I do not know whether this counts as a VXL bug.  Perhaps it must simply
> be a requirement that when compiling with gcc, the -fPIC option must be
> used because even for a build with static libs, since some shared libs
> are also built
I'm also wondering if -fPIC should be considered a standard option for
compiling VXL with gcc on 64-bit systems.  The issue is that we
occasionally want to compile parts of VXL into dynamic libraries.  In
the case of those Brown libraries the goal is to wrap the code into a
Python module.  There is no problem doing this on 32-bit systems, but
-fPIC is required on 64-bit systems.

Is there a good reason not to enable -fPIC by default?  I remember
reading somewhere that it may have an impact on code optimization, but I
don't know the details.  Some people might not build brl nor care about
dynamic linking, so they could potentially benefit from not using
-fPIC.  Is this benefit significant enough to matter?


Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
Vxl-maintainers mailing list