[Buildroot] Notice: significant changes for static linking configurations

[Buildroot] Notice: significant changes for static linking configurations

[Thomas Petazzoni]

Hello,

I've just merged a bunch of changes that make some fairly significant
changes in the handling of static linking cases:

 97703978ac870ce2b14ad144f8e082de82aa2c64 support/libtool: make -static behave like -all-static
 5d66a9b1fb67cf009fe4f15028c02a8386109dc5 package infra: add -static to C/CXXFLAGS
 8d764327a697a2572bba96878972c1a469f864f3 package infra: revert 0a4bd19f
 169141a3eb0dc009a49895ebdc255bfc869ed5af gcc-final: disable shared build for static

Those changes are aimed at fixing the issue we have seen since a long
time when linking certain C++ packages, with messages like:

  /home/test/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.7.3/../../../../x86_64-buildroot-linux-uclibc/bin/ld: attempted static link of dynamic object `/home/test/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.7.3/../../../../x86_64-buildroot-linux-uclibc/lib/../lib64/libstdc++.so'
collect2: error: ld returned 1 exit status

See
http://autobuild.buildroot.org/results/5c7/5c7f804ccc4fe233ae6e48d489cd7a40c64ed68a/build-end.log
for one such example.

So, if you are using BR2_PREFER_STATIC_LIB=y in your configuration,
please do test the latest master, and report back any issue. Basically,
the changes are as follows:

 - Change the internal toolchain backend to not build a shared
   libstdc++ when we're building static only.

 - Change the TARGET_LDFLAGS from --static to just -static, which is
   what the compiler and linker normally expect. -static was also added
   to TARGET_CFLAGS and TARGET_CXXFLAGS for good measure.

 - Addition of more libtool hackery, to make it understand -static as
   meaning "I want things to be built fully statically", which normally
   requires a libtool specific -all-static. But since that flags is not
   understood by the compiler or linker, we cannot pass it to LDFLAGS.
   See the commit log for details.

We'll see in the next few days what is the result of those changes in
the autobuilders. If it turns out to be too nasty, we might revert
back. But the static linking issue with libstdc++ has been around for
too long, it's time to get something done.

Thanks a lot to Gustavo for doing all the initial work, and helping on
IRC ironing out the last details.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Notice: significant changes for static linking configurations

[Thomas Petazzoni]

Hello all,

On Wed, 30 Jul 2014 23:50:26 +0200, Thomas Petazzoni wrote:

> We'll see in the next few days what is the result of those changes in
> the autobuilders. If it turns out to be too nasty, we might revert
> back. But the static linking issue with libstdc++ has been around for
> too long, it's time to get something done.

So, the first major issue that is currently visible in the autobuilders
is related to packages using libtool 1.5 ltmain.sh. It turns out that
by chance and thanks to fuzziness our existing patch for libtool 1.5
was applying fine on a wide range of libtool 1.5.x ltmain.sh scripts,
even though those scripts are quite different depending on the specific
version you're using.

The issue is that for the -all-static / -static change, it's not
possible to do a patch that will apply on all 1.5.x libtool versions.
Options are:

 1) Further refine the libtool version check, and instead of just
    checking for major versions (1.5, 2.2, 2.4), check for the minor
    version as well, so that we can provide different patches for each
    specific libtool version. Notice that it *may* be necessary down
    the road, because with Hadrien we have seen cases of recent
    packages using a specific libtool 2.4.x version on which our
    libtool 2.4 patch was not applying.

 2) Mark AUTORECONF = YES the problematic packages (i.e the ones using
    libtool 1.5) so that their ltmain.sh gets regenerated with libtool
    2.4 and our patch applies. That's the solution we discussed
    yesterday evening with Gustavo, and for which I applied a patch
    this morning. We will see how far this brings us, and whether or
    not we need to get back to (1) for a more long-term solution.

Ideas, suggestions, comments are welcome.

Note that I know we're breaking stuff badly, and we're making
autobuilders all red, but this libstdc++ static linking stuff has been
around for a long time, and we need to fix it at some point. And
without the help of the autobuilders to tell us what breaks, it's
really hard to make progress.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com