From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 17 Feb 2011 00:01:57 -0500 Subject: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL In-Reply-To: <20110215185100.6c6e20fc@schlenkerla> References: <1296498767-26408-1-git-send-email-Haiying.Wang@freescale.com> <201102150402.45553.vapier@gentoo.org> <20110215185100.6c6e20fc@schlenkerla> Message-ID: <201102170001.59271.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday, February 15, 2011 19:51:00 Scott Wood wrote: > On Tue, 15 Feb 2011 04:02:44 -0500 Mike Frysinger wrote: > > > 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)). > > Ah. So why is PLATFORM_LDFLAGS added into both LDFLAGS and > LDFLAGS_u-boot? :-P i'm not saying PLATFORM_LDFLAGS makes sense. it certainly seems like we've outgrown the PLATFORM_XXX flags and could be cleaned up. -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/20110217/515698cf/attachment.pgp