This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Static linked cross tools


Allen,

> 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:
> BINUTILS_EXTRA_CONFIG="LDFLAGS=-all-static
>
> 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
it?

>
> Static linking GCC 3.3.3:
> Cross tools doc:
> GCC_EXTRA_CONFIG="LDFLAGS=-static"
>
> 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 http://gcc.gnu.org/install/configure.html:
"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 libgcc.so 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
libraries."
(...)
"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:

BINUTILS_MAKE_OPTIONS="LDFLAGS=-all-static"
# I would advice against using BINUTILS_EXTRA_CONFIG since it's issued
# to configure - we don't need that
make $BINUTILS_MAKE_OPTIONS all

GCC_MAKE_OPTIONS="LDFLAGS=-static"
# final gcc only
make $GCC_MAKE_OPTIONS all

- To generate a dynamically linked toolchain, only suited to generate static
binaries:
BINUTILS_EXTRA_CONFIG="--disable-shared"

GLIBC_EXTRA_CONFIG="--disable-shared"

GCC_EXTRA_CONFIG="--disable-shared"
(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,
Arno


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]