Re: [Buildroot] [PATCH v8 01/10] package/binutils-bare-metal: new package

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Frager, Neal" <neal.frager@amd.com>
Cc: "Simek, Michal" <michal.simek@amd.com>,
	"Erkiaga Elorza, Ibai" <ibai.erkiaga-elorza@amd.com>,
	"luca.ceresoli@bootlin.com" <luca.ceresoli@bootlin.com>,
	Neal Frager via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH v8 01/10] package/binutils-bare-metal: new package
Date: Thu, 14 Dec 2023 10:15:05 +0100	[thread overview]
Message-ID: <20231214101505.3dcac5e7@windsurf> (raw)
In-Reply-To: <D15E2E86-61C5-4344-8669-FDE201516BF5@amd.com>

Hello Neal,

(It would be good if you could configure your e-mail client to wrap lines).

On Thu, 14 Dec 2023 08:12:35 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:

> > Thing is you will have to explain very clearly what we need a
> > different value, and I'm not sure we have such a clear explanation
> > (at least I don't have it).  
> 
> The clear explanation is that gcc does not find newlib in the sysroot
> directory without this change.  I don’t know how it works with a
> sysroot as currently written.

Well, but it's like that in newlib, and it's been like that for years,
so it must work for others. For example, Crosstool-NG does not seem to
be patching newlib on this aspect, yet it is able to generate
functional bare-metal toolchains, somehow.

> >> If there is a reason, perhaps they can help us with implementing a
> >> configurable solution, as you suggest.  In any case, I think
> >> working to upstream a proper solution is still better than my
> >> fixup solution. I only implemented the fixup solution as it was
> >> quicker than spending many hours learning the newlib configure
> >> script.  Now that you have found the root of the problem, I think
> >> patching it upstream is the best option.  
> > 
> > Many hours to add a --with-option? It should take 10 minutes or so.
> 
> 10 minutes now that we know exactly where the issue is coming from.
> My comment about many hours was based on not knowing any patch
> already existed.  Creating a patch to the configure script from
> scratch would have taken me a few hours.  This is why I did the fix
> up.

I'm not sure we're talking about the same thing. I'm not talking about
the time needed to find the root cause of the issue, but rather the
time to write a patch that actually has a chance to be accepted
upstream. The patch that you have for now has absolutely 0 chances of
being accepted upstream, as it breaks existing behavior that presumably
works for users today.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot