Re: -fpic instead of -fPIC

[Ralf Wildenhues]

Hi Joakim,

* Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 07:21:17PM CEST:
> > * Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 04:10:31PM CEST:
> > > 
> > > I want to use -fpic instead of -fPIC on a powerpc(linux) target since
> > > that generates smaller and faster libs.  But I can't find out how to
> > > make libtool use -fpic. I don't want to do local changes to the
> > > installed libtool.  build host is linux/x86.
> > 
> > The setting of pic_flag is hard-wired in AC_LIBTOOL_PROG_COMPILER_PIC in
> > libtool.m4 now, if that's what you are looking for.
> 
> OK, will look at that some more. I don't automake, autoconf and libtool very 
> well so I need
> a liite guidance here. Can I just run aclocal and modify the generated 
> aclocal.m4? I would 
> then commit aclocal.m4 to CVS and use that when building our libs.

Yes, you can do that.

> Is there a better way?

If you use recent Automake, it might be more favorable for you to create
a subdir `m4' and put all the m4 macro files you need in there
(libtool.m4, ...), and then put
  ACLOCAL_AMFLAGS = -I m4
in $top_srcdir/Makefile.am.

Then you can just edit the files in m4/, but now it will be easier for
you to update them when you want to.  (You still need to make sure
libtool.m4 and ltmain.sh are updated at the same time.)

(At some point in the future, setting
  AC_CONFIG_MACRO_DIR([m4])
in configure.ac will also allow automatic updating of the files in m4/.)

> > But how would you have Libtool find out when it will be used for large
> > sources for which -fpic will fail?
> 
> This is mainly for our own development of onboard SW for a embedded target and
> we want to save space.

OK, then it might make sense to do like above.
Do you perchance build for a different system?  For that it might make
sense to think about setting pic_flag differently (for example if the
usual memory of such an embedded target makes -fPIC obsolete anyway).

> > (Note I *could* imagine some kind of parametrization a la `-small-pic',
> > but I'll tell you right away that the amount of possible breakage is
> > huge, huge, and dangerous, and hard to find only after hours of
> > compilation; and the resulting fights with users..)
> 
> hmm, but in some cases it is justified. Think embedded products.

Valid point.

> > Two questions to ponder before you think about -fpic: Have you measured
> > the speed impact of -fpic vs -fPIC?  Please show, I'm interested!
> 
> Nope, but i did look at the libs with readelf -a and found that accesses to a 
> global
> variables seems to generates a reloc per access to that global variable(why?) 
> and that
> can quickly waste space.

Is the system you build for ELF?  If so, then it's because of the tricky
ELF rules (see below).

> > If the difference is noticeable: Have you slapped the library author
> > with Drepper's dsohowto.pdf yet?  If so, please share with us his/her
> > reasoning to ignore it.   :)
> 
> Nope, not yet. Will have to slap myself and my team in that case :)

Hehe.  :)

> I have read that doc and learned a lot from it. However even Drepper seems
> to like -fpic in one case: glibc for ppc is compiled with -fpic.
> PPC can handle big libs even with -fpic.

I was not thinking of `-fpic' at all.  Rather of -fvisibility=hidden (or
the analogous attributes for non-static functions/variables).

Now the ELF issue (which is much more nicely explained in dsohowto):
Every access to a global variable has to go through reloc each time.
Why?
If the global variable `foo' is defined in libA.so, ELF rules specify
that it must be possible to intercept all use of `foo' (use from
dependent libraries and programs *as well as* use from within libA)
by defining another instance of `foo' in an ELF object linked in before
(possibly only at runtime!).  This is how some memory debugging
libraries work, they "overwrite"  `malloc', `realloc', `calloc' and
`free'.

This may be overridden with GCC by -fvisibility and/or annotations.
All explained very well by Drepper.

My guess would be: once you use that to your advantage (and being
embedded you have the advantage that you don't need to be portable),
there is little need for -fpic over -fPIC any more.  (I'd still like to
see numbers to the contrary! :)

Cheers,
Ralf