Angelo Leto wrote:
On Jan 24, 2008 12:18 PM, Andrew Haley <aph@xxxxxxxxxx> wrote:
Angelo leto wrote:
Hi, I'm trying to build statically all the gcc executables in order to
generate a portable compiler package, in particular I need a package
which is not dependent from a specific dynamic loader version
(ld-linux.so.2), could you please help me to find a way to obtain
this?
For instance I can run gcc using the command "ld-linux.so.2
~/mygcc/usr/bin/c++", but c++ then calls cc1plus which also needs
ld-linux.so.2 ....
The short answer is to set the makefile args to that gcc links with
-static. Simply "make LDFLAGS=-static" might work for you.
I already tried this, but seems not to work.
It works for me. You need to tell us in what way it seems not to
work for you. We can't get far by guessing.
The long answer:
Usually, people who want to do this don't know what they're doing, and
people who do know how to do it wouldn't consider doing it because
they know all the problems it will cause.
Question: which kind of problems could happen if I build gcc without
architecture specific optimizations?
None that I'm aware of, but I'm not sure of the relevance of that question.
When you build gcc you're building it for a specific host/target
combination, and configure autodetects properties of both. It doesn't
usually make much sense to use a gcc that's been built for one host on
a different host.
I'm working on applications which are data critical, so when I change
a library on the system there is the risk that results may be
different, so I create a repository with the critical libraries, and I
upgrade the libraries on repository only when it is needed and
independently from the system libraries (I do this in order to upgrade
the productivity tools and their related libraries without interacting
with the libraries linked by my application). Obviously when I change
the compiler I obtain different results on my applications, so my idea
is to create a "development package" which includes my critical
libraries and also the compiler in order to obtain the same result
(always using the same optimizations flags) on my application also
when I'm compiling on different Linux installations.
All fine and good, but I don't understand why that requires you to link
gcc itself statically. gcc doesn't need very many libraries and you
should be able to include the ones you need.
Even better, build gcc dynamically on the older box.
I guess that the same gcc static binary (e.g. compiled for generic
i386 architecture) should give me the same output on different linux
environments running on i386 machines. Is there any reason for which
this might not be true?
You have to be very careful when linking _anything_ statically against
libc, in particular. See http://people.redhat.com/drepper/no_static_linking.html
Sometimes, however, people build gcc on an old operating system
version and it will run on a newer version. That makes sense for
cross-compilers, in particular.
So, can I ask you what you are really trying to do? Is it that you really need to run on some ancient Linux that really doesn't have
ld-linux.so.2?
All the linux on which I run the applications do have ld-linux.so.2,
but it is different from a glibc version to another. For example when
I use a different version of ld-linux.so.2 I obtain the following :
....
/home/test/svn/external-pkg/gcc_i386_march_pentium4/usr/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus:
relocation error:/home/test/svn/external-pkg/gcc_i386_march_pentium4/lib/libc.so.6:
symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in
file ld-linux.so.2 with link time reference
so I cannot use the same ld-linux.so.2 because they are different.
The problem here looks like you have a different version of libc and ld-linux.so.2.
They're a pair. You can't take them from different versions.
Andrew.
