[U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Mike Frysinger]

On Tuesday, February 01, 2011 15:40:13 Scott Wood wrote:
> Before 8aba9dc, the flags for the final link were produced by taking
> the existing LDFLAGS, and adding:
> -Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.

i think you're skipping a fairly large piece of the picture -- the whole 
reason for 8aba9dc commit in the first place: commit 6d8962e814 (introduction 
of partial linking).  before that commit, the linker was only used in one 
place: the final u-boot link.  because of that, LDFLAGS was only used in one 
place.  so people put both target-specific (u-boot) and linker-specific (ld) 
flags into the same place (LDFLAGS).  but with partial linking, that was no 
longer possible.  we needed a way to differentiate between the two and thus 
LDFLAGS_$@ was born.

so commit 8aba9dc is not something made for fun, but to fix real bugs people 
were seeing while building with bi-endian toolchains (arm/superh/mips/probably 
others), or bi-abi toolchains (blackfin/arm/probably others).

> This included anything that cpu/board code added to LDFLAGS -- some
> architectures added --gc-sections, x86 added --cref, etc.  Since the above
> flags are added to LDFLAGS, rather than replacing them, these flags got
> used in the final link.
> 
> Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
> source for the flags for the final link.  It generates LDFLAGS_u-boot using
> PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates
> to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

err, i dont think this is correct.  LDFLAGS is no longer the *only* source for 
the final link.  if you look at the actual target, you'll see it using 
$(LDFLAGS) $(LDFLAGS_$(@F)).

> I don't see any other LDFLAGS changes in board/cpu code, so the distinction
> between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
> current boards.  However, the patch appears to be intended to support
> platform linker flags that need to be used during partial link, which
> would involve board/cpu additions to LDFLAGS.  This change would break that
> only if those options need to be used for partial link *only*, and cannot
> be used in the final link.  In such a case I'd suggest using something
> like LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
> were actually the case.

if Linux hasnt had an issue with flags that are valid only during partial 
linking, then i dont think u-boot will either.

> If you're looking to cut down on the number of variables, it's not clear to
> me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
> LDFLAGS.

historically, ive never really seen much (any?) value in the split between 
PLATFORM_XXX and XXX.  i say we kill all the PLATFORM_XXX cruft.

ultimately, LDFLAGS_FINAL makes sense to me.  we cant override LD, nor can we 
override LDFLAGS, and it sucks if people have to duplicate flags in multiple 
variables when all they care about is the final link.  it's unavoidable pain 
imo born of attempting to build & finally link multiple applications in a 
single tree.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110215/67685ccc/attachment.pgp