Hi Maheedhar,
I think Boyan’s analysis and advice is right on both counts, and it’s likely `ENABLE_LTO` was not being enabled even with the patch.
LTO has also only ever been supported by linking via GCC. The build system is capable (as of relatively recently) of determining the proper toolchain automatically, so for your case you can omit `CC`, `LD` and `CROSS_COMPILE` entirely and it should automatically pick up the correct linker.
We (Arm) generally try to avoid touching platforms that we can’t ourselves test directly, but if you need assistance with getting this working then I can help to get it building at least.
Chris
From: Boyan Karatotev Boyan.Karatotev@arm.com Date: Monday, 6 January 2025 at 09:43 To: Bollapalli, Maheedhar Sai MaheedharSai.Bollapalli@amd.com, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Cc: Simek, Michal michal.simek@amd.com, Chris Kay Chris.Kay@arm.com Subject: Re: [TF-A] Re: Linker errors with ENABLE_LTO and LD overriding Hi Maheedhar,
Till 2.10 if we use LD=aarch64-none-elf-ld directly as build command parameter there was no problem with the build but with ENABLE_LTO patch we got build problems.
Ah right I see. Well, if I'm reading the mailing list thread on the patch you linked correctly, before that patch ENABLE_LTO in platform.mk wouldn't have had any effect. So perhaps it was never building with ENABLE_LTO? I tried it locally on v2.10 with ENABLE_LTO on the commandline and the same error came up.
So by the sounds of it ENABLE_LTO is broken anyway. @Chris, any ideas?
Are there any generic recommendations on what to use for LD variable (LD=aarch64-none-elf-gcc & LD=aarch64-none-elf-ld) and any plan further in upstream to fix this issue for ENABLE_LTO case.
I'm pretty sure that the intention is that if you want LTO, then LD=aarch64-none-elf-gcc is the only one that should work. I'll let Chris confirm.
Boyan