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