Re: [Vxl-maintainers] vxl 1.14 beta 1 - linux with gcc test build

[Chuck A. <chu...@ki...>]

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 <mat...@ki...> 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/bbgm_batch.so
> > /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:
> >
> > http://www.cdash.org/CDash/viewBuildError.php?buildid=557176
> >
> > 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?
>
> Matt
>
>
> ------------------------------------------------------------------------------
> 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.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>