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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
