Static linked cross tools

Arno Schuring
Fri Oct 15 21:39:00 GMT 2004


> I am trying to resolve the static tool build issue. After reviewing the
> crosstool documentation, posted messages and the binutils/GCC
> documentation, I am a little confused.
> Static linking BinUtils 2.15:
> Cross tools doc:
> Posted Messages:
> Change make to:  make $BINUTILS_EXTRA_CONFIG all
> Configuration options:
> configure --enable-static
> OR
> configure --disable-shared?

the --enable-static options is not in binutils' README - where did you find

> Static linking GCC 3.3.3:
> Cross tools doc:
> Configuration options:
> configure --disable-shared
> So, it looks like it should be a configuration option, not a linker
> flag. Does anyone have a definitive answer on this?

Short answer:

The options --disable-shared and --enable-shared determine what type of
binaries the tools can generate, not how the tools themselves are generated.

Long answer:

- According to
"Use --disable-shared to build only static libraries"

This will not result in a statically linked compiler, but will result in a
compiler without the dynamic library - in other words, it will not
be able to generate code that is dynamically linked *against the gcc
libraries*. Of course it can link dynamically against glibc or other libs.

- According to binutils-CVS/binutils/README:
"You can also specify the --enable-shared option when you run
configure.  This will build the BFD and opcodes libraries as shared
"The binutils will be linked against the shared libraries."

For binutils, the default is to build dynamic libraries and link against
them. If you specify --disable-shared, the libbfd and libiberty will not be
generated, however I assume binutils will still be linked dynamically
against the host's glibc.

- For glibc:
--disable-shared will result in no dynamic libraries, so all target programs
will have to be statically linked, I assume.

So the question is:
Why do you want statically linked tools? Do you need to run the tools on
different systems with different libraries, or any other reason to not use
dynamic libraries *to run the tools in the toolchain*? Or do you only need
your crosstools to generate statically linked programs?

- For statically linked crosstools, but still the ability to build
dynamically linked targets:

# I would advice against using BINUTILS_EXTRA_CONFIG since it's issued
# to configure - we don't need that

# final gcc only

- To generate a dynamically linked toolchain, only suited to generate static


(this is untested by me)

I do not believe the above are mutually exclusive, you can probably use both
to generate a statically linked toolchain that can only generate statically
linked targets.

I have little time to spare on my hands now, I'm sorry I can't give you any
tested configurations. I have generated several statically linked toolchains
by hand, using above sequence, though.

Hope this helps,

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list