|
|
Onno Garms <garms@xxxxxx> writes:
> Thanks. My question was based on the (wrong?) assumption that it
> varies upon the compiled program which libraries are linked.
I know of no compiler driver which varies libraries depending on
objects being linked. The set of libraries usually depends only on
compiler and linker options you specify on command line.
> Is the list independent of the program?
Yes, usually.
> Then the complete list according to -v
> (which I had tried before) is:
> -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
Note that it is "bad form" to encode that list into your Makefile
-- it may change between compiler versions, may be different
on different OSes, and also changes with other options,
e.g. -static-libgcc.
> 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.
Nothing strange: libstdc++.so very likely also depends on these
libraries.
> So does the -static switch make any sense?
Sometimes: you could be linking a system utility which must work
even when shared libraries are not available (perhaps this utility
helps you restore system to sanity; as an experiment try "rm -f
/lib64/libc.so.6", and then see if you can fix the system without
a complete reinstall).
Or you could be linking an image for an embedded system, on which
you know exactly which version of glibc will be used.
>> 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.
You have to examine the actual link command that g++ constructs to
understand why it is so difficult to get rid of dynamic libstdc++.so
dependency.
>> So you must either link on the
>> oldest OS you plan to support, or use "tricks", such
>> as Linux-to-(older)Linux cross-compiler, 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.
Apgcc is actually quite easy to use. Keeping an old system isn't
that difficult either.
> 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?
Do "readelf -V Onno" -- this should tell you which minimum version
of glibc you require. According to distrowatch.com, SuSE 10.3
shipped with glibc-2.6.1. That is *very* new, and your binary is
quite likely to require at least glibc-2.4, which will make it fail
to start on quite a number of installed systems. On Linux/x86_64,
I've been building on RHEL-3, which shipped with glibc-2.3.2, which
is one of the earliest versions of glibc to have x86_64 support;
and I haven't seen any system where my binaries fail to run.
> *) 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
AFAICT, SuSE 10 shipped with glibc-2.3.5. The fact that you can run
on SuSE 10.0 means you don't have any dependencies on glibc-2.4,
but that may be just by luck; you can't count on that.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|