Re: statically linked gcc executables

["Angelo Leto" <angleto at gmail dot com>]

On Jan 24, 2008 5:12 PM, Andrew Haley <aph@redhat.com> wrote:
> 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 steps I execute are:
1) I downloaded gcc-4.2.2 from
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.2.2/gcc-4.2.2.tar.bz2
2) enter gcc-4.2.2
3) make LDFLAGS=-static
4)  /usr/local/src/gcc-4.2.2 # ldd host-i686-pc-linux-gnu/gcc/cc1plus
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/libc.so.6 (0xb7e94000)
        /lib/ld-linux.so.2 (0xb7fdd000)

>
> >> 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.

because I want to run gcc also on linux installed with different
version of glibc.

>
> Even better, build gcc dynamically on the older box.

I tryied, but does not work on linux with new libc ...

>
> > 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

i will carefully read it.

>
> >> 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.

I know, in fact I want to use the gcc compiled using libc 2.6 on a
system whith libc 2.3, and to do this you must run the c++ using the
command:
ld-linux.so.2 c++
where the loader is the one coming with libc 2.6.
And this work, but gcc call cc1plus and it also need to be executed
using the ld-linux.so.2 from libc v2.6.

bye.
Angelo
>
> Andrew.
>