[PATCH] Add support for static toolchains
Yann E. MORIN
yann.morin.1998@anciens.enib.fr
Sun Oct 17 17:12:00 GMT 2010
Bryan, All,
On Friday 15 October 2010 19:54:34 Bryan Hundven wrote:
> # HG changeset patch
> # User Bryan Hundven <bryanhundven@gmail.com>
> # Date 1287163549 25200
> # Node ID 723f12354ba302905f8398b9d4bc2697e780a247
> # Parent 3b812ba8d0019ae5c283b3848bd3461ae17195aa
> Add support for static toolchains
Thank you for updating this! :-)
I however have a few comments. See inline.
[--SNIP--]
> diff -r 3b812ba8d001 -r 723f12354ba3 scripts/build/binutils/binutils.sh
> --- a/scripts/build/binutils/binutils.sh Sat Oct 09 11:38:04 2010 +0200
> +++ b/scripts/build/binutils/binutils.sh Fri Oct 15 10:25:49 2010 -0700
[--SNIP--]
> @@ -66,6 +76,7 @@
> # Now on for the target libraries
> do_binutils_target() {
> local -a extra_config
> + local -a extra_make_flags
This is binutils libs for the target. It should not be impacted by the
'staticity' of the toolchain proper.
I would understand "static toolchain" as applying to executables running
on the host be static, not stuff running on the target.
It be might be interesting to have a toolchain using only static libs on
the target, but this is another thing.
> local -a targets
> local -a build_targets
> local -a install_targets
> @@ -77,6 +88,10 @@
> build_targets+=("all-${t}")
> install_targets+=("install-${t}")
> done
> +
> + if [ "${CT_STATIC_TOOLCHAIN}" = "y" ]; then
> + extra_make_flags+=("LDFLAGS=-all-static")
> + fi
>
> if [ "${#targets[@]}" -ne 0 ]; then
> CT_DoStep INFO "Installing binutils for target"
> @@ -99,8 +114,13 @@
> ${CT_ARCH_WITH_FLOAT} \
> ${CT_BINUTILS_EXTRA_CONFIG}
>
> + if [ "${CT_STATIC_TOOLCHAIN}" = "y" ]; then
> + CT_DoLog EXTRA "Prepare binutils for static build"
> + CT_DoExecLog ALL make configure-host
> + fi
> +
> CT_DoLog EXTRA "Building binutils' libraries (${targets[*]}) for target"
> - CT_DoExecLog ALL make ${PARALLELMFLAGS} "${build_targets[@]}"
> + CT_DoExecLog ALL make "${extra_make_flags[@]}" ${PARALLELMFLAGS} "${build_targets[@]}"
> CT_DoLog EXTRA "Installing binutils' libraries (${targets[*]}) for target"
> CT_DoExecLog ALL make DESTDIR="${CT_SYSROOT_DIR}" "${install_targets[@]}"
>
> diff -r 3b812ba8d001 -r 723f12354ba3 scripts/build/cc/gcc.sh
> --- a/scripts/build/cc/gcc.sh Sat Oct 09 11:38:04 2010 +0200
> +++ b/scripts/build/cc/gcc.sh Fri Oct 15 10:25:49 2010 -0700
> @@ -305,8 +305,8 @@
> # Build final gcc
> do_cc() {
We do indeed want the final cc to be static. But what about the core cc?
I know it is only a temporary build, and that it does not get into the
toolchain proper. But would it also make sense to also build it static?
I don't care either way, but I'm telling just for the sake of completness.
> local -a extra_config
> + local -a final_LDFLAGS
> local tmp
> - local final_LDFLAGS
>
> # If building for bare metal, nothing to be done here, the static core conpiler is enough!
> [ "${CT_BARE_METAL}" = "y" ] && return 0
> @@ -389,11 +389,16 @@
> # see http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01635.html
> extra_config+=("--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm")
> elif [ "${CT_COMPLIBS_SHARED}" != "y" ]; then
> + if [ "${CT_STATIC_TOOLCHAIN}" = "y" ]; then
> + final_LDFLAGS+=("-static")
> + extra_config+=("--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm")
> + fi
> # When companion libraries are build static (eg !shared),
> # the libstdc++ is not pulled automatically, although it
> # is needed. Shoe-horn it in our LDFLAGS
> # Ditto libm on some Fedora boxen
> - final_LDFLAGS='-lstdc++ -lm'
> + final_LDFLAGS+=("-lstdc++")
> + final_LDFLAGS+=("-lm")
> fi
> if [ "${CT_CC_GCC_USE_GMP_MPFR}" = "y" ]; then
> extra_config+=("--with-gmp=${CT_COMPLIBS_DIR}")
> @@ -451,7 +456,7 @@
> # embedded systems don't really need message catalogs...
> CC_FOR_BUILD="${CT_BUILD}-gcc" \
> CFLAGS="${CT_CFLAGS_FOR_HOST}" \
> - LDFLAGS="${final_LDFLAGS}" \
> + LDFLAGS="${final_LDFLAGS[@]}" \
Although this is working as you expect, I'm a bit uneasy with this one.
In fact, the man page for bash states that "${ARRAY[@]}" expands to as
many words as there are items in the array. So I would have expected
VAR="${ARRAY[@]}" expand to VAR="ITEM1" ["ITEM2" ...]
On the other hand, "${ARRAY[*]}" expands to a single word, with every
items separated by the first word of IFS.
As we do not want multiple words here, I'd rather we be explicit, and
we use "${final_LDFLAGS[*]}".
Also, you're missing another component that runs on the host: the cross-gdb.
There is already an option to build it statically, so it should be really
easy to also apply this "static toolchain" option to the cross-gdb.
Overall, it is good. Would you care to repost an amended version, please?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list