statically linked gcc executables

[Andrew Haley]

Angelo Leto wrote:
> On Jan 24, 2008 12:18 PM, Andrew Haley <aph@redhat.com> 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.