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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
