Re: [jamboost] problem with -fPIC flag

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-25 02:46:13

On Thursday 20 January 2005 16:28, Toon Knapen wrote:
> Vladimir Prus wrote:
> >>The solution I see is adding following to gcc.jam
> >><quote>
> >>if [ os.name ] != CYGWIN && [ os.name ] != NT
> >>{
> >> flags gcc.compile OPTIONS <link>shared/<main-target-type>LIB : -fPIC ;
> >>+ flags gcc.compile OPTIONS <link>shared/<main-target-type>OBJ : -fPIC ;
> >>}
> >></quote>
> >>
> >>Can anybody tell me if this is indeed the way to go?
> >
> > Looks like a reasonable solution for me. The downside is that now all
> > targets defined with "obj" will be compiled with -fPIC, not only when
> > they are part of a shared library.
>
> Indeed I see that happen although I did not suspect it. IIUC the
> '<link>shared' means that it should only be applied _if_ the OBJ is used
> for a shared library, right ?

In fact, until now <link>shared made any difference only to "lib" targets. 

> > This can be avoided by using some new <shared-linkable> property but
> > target paths will become even longer. When I introduce automatic
> > computation if properties relevant to a target, this might not be a
> > problem, but until now, the above code seems the most reasonable.
>
> Considering -fPIC can have a considereable influence on performance, I
> guess we don't want to use the flag for compiling objects for static
> libraries. Or do you think this is not an issue ?

Given that most current applications are heaps of shared libraries with very 
little wrapper around it, I would say that the performance impact should not 
matter much. If it mattered, everybody would be screaming loud.

- Volodya