libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -fpic instead of -fPIC


From: Ralf Wildenhues
Subject: Re: -fpic instead of -fPIC
Date: Tue, 7 Jun 2005 09:03:12 +0200
User-agent: Mutt/1.4.1i

Hi Joakim,

* Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 11:15:40PM CEST:
> > * Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 07:21:17PM CEST:
> > > 
> > > 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

I get confused sometimes about the rebuilding rules.  configure.{ac,in}
should be a dependency of aclocal.m4, so you should make sure it's not
newer.  There are more possible dependencies..

> > > 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 :(

First off: 1.4-p6 is _anything_ but recent.  I believe 1.9.5 is the most
recent stable release.  There have been numerous changes since 1.4, some
may need you to adjust your source somewhat (the first and second digit
specify the Automake interface version), but honestly, I can't tell you
much about 1.4.

After you have updated Automake, and modified m4/libtool.m4, run
  aclocal -I m4
(this should be done automatically with the line I mentioned above, and
with autoreconf; but please again, use a recent Autoconf as well).

Just to answer your next question: It is very wise to install all of the
Autotools into the same $prefix...

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

Please specify Libtool version used, the command line issued to build
the libraries, and what libtool outputs.  My guess would be that you
omit the `-rpath ...' argument and libtool creates convenience archives.
I don't know about the ancient Automake, but recent ones add this
argument to the command line for libs not in noinst_* variables.

> Still on configure.in :)

No problem.

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

Yes, certainly.  Sorry for the confusion.

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

Libtool (still) has many shortcomings when it comes to cross
compilation.

*snip stuff that I agree with and needs no further comment*
>
> > 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?
*snip*
> 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.

Hmm.  I'd need to look at linker docs in order to be able to comment on
this (it's been a while), sorry.

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

Same here.

Regards,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]