Re: git: 4c0dfd5959bd - main - arm: fail early on gcc builds

From: Brooks Davis <brooks_at_freebsd.org>
Date: Fri, 17 May 2024 17:42:56 UTC
On Fri, May 17, 2024 at 04:27:14PM +0000, Brooks Davis wrote:
> On Fri, May 17, 2024 at 09:14:46AM -0700, John Baldwin wrote:
> > On 5/17/24 9:01 AM, Brooks Davis wrote:
> > > The branch main has been updated by brooks:
> > > 
> > > URL: https://cgit.FreeBSD.org/src/commit/?id=4c0dfd5959bd499754e3fc9a7ce37c1d5ece31f7
> > > 
> > > commit 4c0dfd5959bd499754e3fc9a7ce37c1d5ece31f7
> > > Author:     Brooks Davis <brooks@FreeBSD.org>
> > > AuthorDate: 2024-05-17 15:47:22 +0000
> > > Commit:     Brooks Davis <brooks@FreeBSD.org>
> > > CommitDate: 2024-05-17 16:01:19 +0000
> > > 
> > >      arm: fail early on gcc builds
> > >      Since at least 2022 (see https://reviews.freebsd.org/D36754), it has
> > >      not been possible to build armv6/armv7 with gcc due to atomics macros
> > >      gcc doesn't like.  Prevent developers doing due diligance from wasting
> > >      time and CPU cycles on this combination as it just fails to build in
> > >      libc.
> > >      Reviewed by:    imp, andrew
> > >      Differential Revision:  https://reviews.freebsd.org/D45193
> > 
> > As I said in the review, this is a weird change.  Only amd64 and i386 build
> > with GCC.  You should blacklist all the others if you are going to blacklist
> > any, not just 32-bit arm.  I hadn't blacklisted any to make it possible for
> > other developers to work on it.  Also, the review in question is probably not
> > the right fix, it's probably that we need to pass different CFLAGS to GCC for
> > 32-bit arm.
> 
> I think I misunderstood your point in the review.  I've wasted days
> trying to do the right thing to let me reapply 4510f2ca9170 (Make
> WITHOUT_UNDEFINED_VERSION the default) only to find that it's secret
> knowledge that gcc builds are broken except on x86.
> 
> IMO there's less than zero value in universe targets that don't work
> unless they are clearly fenced.
> 
> I propose disabling all the others and adding a flag to ignore this
> guard.

I've implemented this in https://reviews.freebsd.org/D45230

-- Brooks