[PATCH] Add support for static toolchains

[Bryan Hundven]

On Sun, Oct 17, 2010 at 10:12 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> 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.

Oops, I forgot to remove the static options for the target. That was
just an experiment. Sorry ;)

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

So, the gcc_core_shared should be another gcc_core_static?
I will start working on that if that is what you mean.

>>      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[*]}".

Ok.

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

Do you mean in 'config STATIC_TOOLCHAIN' to add:
depends on GDB_CROSS_STATIC

> Overall, it is good. Would you care to repost an amended version, please?

It wouldn't be a problem at all. When I get answers to my two
questions, I will post my revision.

> Regards,
> Yann E. MORIN.


Thank you,

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq