From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Sun, 16 Oct 2016 12:05:10 +0200
Subject: [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with
 toolchain-wrapper
In-Reply-To: <1459885521-25434-1-git-send-email-heyleke@gmail.com>
References: <1459885521-25434-1-git-send-email-heyleke@gmail.com>
Message-ID: <20161016120510.55c138f0@free-electrons.com>
List-Id: <buildroot.busybox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: buildroot@busybox.net

Hello,

On Tue,  5 Apr 2016 21:45:18 +0200, Jan Heylen wrote:
> extend the toolchain wrapper to also wrap the ld linker.
> 
> Tested with gnu ld and gnu 'gold'
> BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default --enable-plugins"
> 
> make host-binutils result in: (ld and ld.gold are equal)
> <ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper
> <ARCH>-buildroot-linux-uclibc-ld.bfd
> <ARCH>-buildroot-linux-uclibc-ld.br_real
> <ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper
> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
> <ARCH>-linux-ld -> toolchain-wrapper
> <ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real
> <ARCH>-linux-ld.gold -> toolchain-wrapper
> <ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
> toolchain-wrapper
> 
> after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld
> symlinks remain
> 
> Based upon patch from Thomas Petazzoni:
> http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942

We had a discussion at the Buildroot Developers meeting today about
this patch series. After discussion, we concluded that there should be
no need to wrap ld. ld should not be used directly, except in very
specific cases, where the caller knows what it is doing and should pass
the right arguments.

As far as we know, the only case that was broken was the libiscsi
package, but such a package should definitely *not* use ld directly. So
the fix should be done in libiscsi, not in the wrapper.

However, your patch series triggered a very useful discussion about
reworking how flags are handled by the wrapper, and we took the
following notes of things to do:

 - We want to refactor how the CFLAGS are handled by the wrapper:

   - Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a
     single BR2_TARGET_EXTRA_FLAGS

   - Have a make variable called TARGET_WRAPPER_FLAGS that includes
     all flags we want to include in the wrapper:

      * $(TARGET_ABI)
      * $(TARGET_CPPFLAGS)
      * $(BR2_TARGET_EXTRA_FLAGS)
      * Custom flags added by package/Makefile.in

     $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the
     wrapper.

   - TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
     TARGET_CXXFLAGS = $(TARGET_CFLAGS)
     TARGET_LDFLAGS = $(TARGET_CFLAGS)
     TARGET_FCFLAGS = $(TARGET_CFLAGS)

   - The wrapper, instead of having special cases for different flags,
     just receives (at build time), the list of hardcoded flag. A
     special logic needs to be put in place to handle precious flags
     (mcpu, march, mtune, mfloat-abi, etc.), for which the
     command-line passed flag must be preserved if passed.

 - Define LD to "false" in $(TARGET_CONFIGURE_OPTS) so that we detect
   the crappy packages that use LD directly. Individual packages can
   still pass LD=$(TARGET_LD) or LD=$(TARGET_CC) if really needed.

We're of course not asking you to work on those topics. Arnout has
volunteered to do it already.

Best regards,

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