gnu.gcc.help
[Top] [All Lists]

Re: standard system libraries and -static option

Subject: Re: standard system libraries and -static option
From: Onno Garms <garms@xxxxxx>
Date: Mon, 14 Jul 2008 10:33:47 -0700 (PDT)
Newsgroups: gnu.gcc.help

First of all, thank you for your very helpful reply.

On 14 Jul., 06:38, Paul Pluzhnikov <ppluzhnikov-...@xxxxxxxxx> wrote:

> In that case, link dynamically against all system libraries.
> Contrary to popular belief, static linking does not produce portable
> binaries on UNIX.

Thank you for pointing out.

> > 1.) Where can I find a ful list of these standard system libraries?
> > (Or, more basically, does a request for such a list make sense?)
>
> Perform 'gcc -v' or 'g++ -v' -- this will show what the actual link
> command is.

Thanks. My question was based on the (wrong?) assumption that it
varies upon the compiled program which libraries are linked. In that
case a single -v would not be able to answer the question. Is the list
independent of the program? Then the complete list according to -v
(which I had tried before) is:
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc

> > 2.) How does the compiler decide wich standard system libraries
> > actually to include? I found (using ldd or objdump) that a hello-world
> > program does not include any.
>
> This statement is very likely false:

You are right. I must have done something wrong. I think I used
objdump to show the dependencies, but I verified today and found
dependencies.

> > My program depends on stdc++, c, gcc_s,
> > and m, of which gcc_s is only needed indirectly (by stdc++) and m not
> > at all.
>
> You must have linked with g++ then.

Yes. My program is written in C++, so I have to link with g++.

> I am wondering how you came to the (possibly incorrect) conclusion
> that libm is not needed at all, and that libgcc_s is only needed
> indirectly?

First I did:
> ldd -u Release/Onno
Unused direct dependencies:
        /lib64/tls/libm.so.6
        /lib64/libgcc_s.so.1

Then I relinked with
-nodefaultlibs -lstdc++ -lc
and got a working executable.

As gcc_s and m are no longer on the link line, even when displayed by -
v, I concluded that the program is not linked against them directly.
But now I checked with ldd and objdump and still found the gcc_s
dependency. Strange.

As for libm, it's gone from the *direct* dependencies according to
objdump and ldd -u, but ldd Release/Onno still shows a dependency on
it. I concluded that it is not needed from the fact that linking with
libstdc++.a -lgcc_s -lc
produces a working executable that does not depend on libm according
to ldd.

> > 3.) What does -static link into my executable?

> It is also likely that the result will be much less
> portable: on newer Linux distributions, you are likely to get a
> warning similar to this:

So does the -static switch make any sense?

> > 4.) What is the "official" way to link only some libraries statically?
>
>   gcc ... -Wl,-Bstatic -lfoo -lbar -Wl,-Bdynamic -lbaz
>
> Above links libfoo.a and libbar.a, but leaves libbaz as "default search".
>
> Note that this doesn't work for libstdc++ and libgcc_s.
>
> A recipe for getting rid of libgcc_s.so and libstdc++.so dynamic
> dependency can be found 
> here:http://groups.google.com/group/comp.unix.programmer/msg/16aaa50e2d88cf8

Thanks. That seems to solve my problems. But why have I got to symlink
libstdc++.a? Putting the path to it in the -L option seems not to
work.

> In addition, note that UNIX systems maintain backwards compatibility:
> older dynamically linked binaries continue to run on newer systems.
>
> So you must either link on the
> oldest OS you plan to support, or use "tricks", such
> as Linux-to-(older)Linux crosscompiler, or apgcc (http://autopackage.org).

Both looks difficult. Either maintain an old Linux for compiling, best
with the current release of gcc because of more performant
executables, or install and use a crosscompiler.

My conclusion from all above is that I merely want to compile with
  g++ -o your.exe main.o ... -L. -static-libgcc
where libstdc++.a is in .
The result will run on all Linuxes unless they have a *very* old
GLIBC. *)
Is that correct?

*) I don't have a zoo for testing. What works now is compiling on Suse
10.3 with GLIBC 2.6 and running on Suse 10.0 with GLIBC 2.3. ldd now
sais
ldd -v Onno
        libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaaabc2000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaaad19000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)

        Version information:
        ./Onno:
                ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-
x86-64.so.2
                libc.so.6 (GLIBC_2.3) => /lib64/tls/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /lib64/tls/libc.so.6
        /lib64/tls/libm.so.6:
                libc.so.6 (GLIBC_2.2.5) => /lib64/tls/libc.so.6
        /lib64/tls/libc.so.6:
                ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-
x86-64.so.2
                ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-
x86-64.so.2
                ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-
linux-x86-64.so.2

Btw. I had tried -static-libgcc on Saturday myself, but was fooled by
the fact that -static-libgcc is effectless when libstdc++.a is not
found because of missing -L option.

Thanks again,
Onno

<Prev in Thread] Current Thread [Next in Thread>