[PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini at konsulko.com> 於 2025年12月2日週二 上午2:27寫道：
>
> On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> > Tom Rini <trini at konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> >
> > >
> > > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini at konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > > >
> > > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > > Tom Rini <trini at konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > > >
> > > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > > Tom Rini <trini at konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > > >
> > > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > > your computer.]
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > > truncated”.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > > >
> > > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > > >
> > > > > > > > > > Nop unfortunately not.
> > > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > > builtin changing significantly.
> > > > > > > > >
> > > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > > or branch listed?
> > > > > > >
> > > > > > > We do not currently have a test for anything other than "newer than
> > > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > > kernel is?).
> > > > > > >
> > > > > > > --
> > > > > > > Tom
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > Oops, missing the kernel version. Add it back for better debug.
> > > > >
> > > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > > version of gcc can be used. We don't have a check, and should, but also
> > > > > the versions in question here should be expected to work. There's just
> > > > > some change we're missing.
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > So long story short this patch itself should not introduce from beginning.
> > > > It is a GCC version depended issue.
> > > > But how to pin-point down to which version is a bit hard.
> > > > Distro link with GCC version and not all gcc version can easily checked.
> > > >
> > > > Any idea how to easily check this?
> > >
> > > We can use the check we have today in arch/arm/config.mk under
> > > "checkgcc6" to check for something much newer. But! It's a problem of a
> > > missing kbuild change I think, based on when this problem was first
> > > reported.
> > >
> > > --
> > > Tom
> >
> > Tom,
> >
> > For GCC version sub-version do not matters?
> > For example 6.x.x 7.x.x 8.x.x
> > Or 9.3 9.4 etc also matters?
> > So to determine the supported version it just need to pin-point to
> > the major GCC version?
> > Then the possible version break only <=10 or <10?
> > Based on the previous build success case.
> > 9.2.0 fails 11.4.0 passed.
>
> Looking through logs now, I see the kernel says 8.1 or newer:
> https://www.kernel.org/doc/html/latest/process/changes.html which is why
> I have been saying there's an underlying kbuild problem (missing
> change(s)) that needs to be resolved. I don't know if 10.x works or
> fails, but that's still beside the point to me as 9.2.0 should work.
>
> --
> Tom

Do this apply to arm-linux-gnueabihf-gcc ?
Or the 8.1 is apply to base gcc not cross-compile?
Just want to confirm.

Brian