[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: -fpic instead of -fPIC
RE: -fpic instead of -fPIC
Mon, 6 Jun 2005 23:15:40 +0200
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:
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
> 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
> > > (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
> 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.
> 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
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
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