This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Option -static
On Thu, Jan 07, 2010 at 07:55:30AM -0800, Takis Psarogiannakopoulos wrote:
> On Thu, 7 Jan 2010, Ian Lance Taylor wrote:
>
> >
> > As far as I can tell that is not how GNU ld works. When -static is in
> > effect, GNU ld will only find libNAME.a, not libNAME.so. Can you show
> > me an example which shows the behaviour you describe?
>
> Just test the out of the box 2.20 gnu ld and you are right in that issue,
> wont link if the .a is not there, I am using a custom build "2.11a"
> (before gold) which doesnt seem to be bothered about this so have been
> hacked? Or the ld behaviour was changed on the way to 2.20.
No, GNU ld always behaved that way.
> In any case my point was that it is nice if you you have most of the libs
> in static form --static to "prefer" static objects than shared ones
> instead just failing with with a fatal error.
> Picture the following: we have a system that for A,B,C reason the libc is
> available only in a shared form. If your executable depends from another,
> say three, libs that all are exist in static form its really shame that
> the ld wouldnt link the final executable. In order to succeed then an
> "almost static" link you would have to hack the makefiles etc in order to
> pass in the command line the exact .a long filenames cause if the .so
> correspondings are present ld would prefer them.
You can use -Bstatic -la -lb -ld -Bdynamic -le
to link liba.a, libb.b, libd.a and libe.so (or libe.a if libe.a doesn't
exist).
Jakub