[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