statically linked gcc executables

Angelo Leto
Fri Jan 25 12:38:00 GMT 2008

On Jan 24, 2008 5:12 PM, Andrew Haley <> wrote:
> Angelo Leto wrote:
> > On Jan 24, 2008 12:18 PM, Andrew Haley <> 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
> >>> (, could you please help me to find a way to obtain
> >>> this?
> >>> For instance I can run gcc using the command "
> >>> ~/mygcc/usr/bin/c++", but c++ then calls cc1plus which also needs
> >>> ....
> >> 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
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 =>  (0xffffe000) => /lib/ (0xb7e94000)
        /lib/ (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

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
> >>
> >
> > All the linux on which I run the applications do have,
> > but it is different from a glibc version to another. For example when
> > I use a different version of 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/
> > symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in
> > file with link time reference
> >
> > so I cannot use the same because they are different.
> The problem here looks like you have a different version of libc and
> 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: 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 from libc v2.6.

> Andrew.

More information about the Gcc-help mailing list