RE: -fpic instead of -fPIC

[Joakim Tjernlund]

Hi Ralf, thanks for your input

> 
> 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.

Just did that but aclocal.m4 got regenerated by the build. hmm, need to look 
some more at 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.

Is 1.4-p6 recent enough? Seems so. I have copied libtool.m4 to my local m4 dir 
and modified it to:
AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_compiler_pic, '-fpic')])
but so far no luck :(

Just noticed another problem: All my libs are created without ".so" suffix.
This is on a debian(prerelease of 3.1) 

> 
> 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/.)

Still on configure.in :)

> 
> > > 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).

pic_flag ? I was thinking of lt_prog_compiler_pic.

I am crossbuilding from linux/x86 to linux/ppc. semtimes we build for linux/x86 
to test.

> 
> > > (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).

Yes, all ELF

> 
> > > 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).

Ah yes, that is something that should be worked upon. But we also
use external libs and we don't have the manpower to "hide" all non
global identifiers.

> 
> 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'.

yes, but within a lib you should only need one reloc for all accesses, right?
If I compile 2 files into a lib, each referencing foo once, I get two relocs 
for foo.
If I compile 1 file into a lib that reference foo twice, I get one reloc.

The linker should be able to combine the first example into one reloc.

> 
> 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! :)

well, if the first example above is fixed somehow that may be true one day :)

Another thing thats annoying is that a string constant needs a reloc(on PPC).
Gcc/ld should be able to merge all/most such relocs into one, atleast all in one
source file.