Could you share how to reproduce the build failure?

If only on my own CI:
https://github.com/dosemu2/dosemu2/actions/runs/13136822663/job/36662916337

aarch64-linux-android-clang   -o tmp.o tmp.s
ld.lld: error: undefined symbol: main

is what you see near the end of the log.
Had to override AS variable, but this
is a very bad thing to do as now it may
fail on some other environment...

The run with work-around applied:
https://github.com/dosemu2/dosemu2/actions/runs/13136822663/job/36665587806

Here you can see:

aarch64-linux-android-clang -x assembler -c   -o tmp.o tmp.s

somewhere in the middle of a huge log.

I don't know whether setting AS to clang -c will break the build in other cases...

I think someone should just
try a full rebuild with that. If
no regressions - commit and
forget. :)

I ran full rebuild of the packages and found no difference in setting AS variable to *-clang -c.
So I believe its safe to make this change.

truboxl#437

Thank you.
I didn't know it requires
such a huge patch-set.
But I'll be happy to revert
my work-around and test
your work immediately
once applied.

My conclusion from the rebuild is that forcing a specific AS will break some builds. The existing set up AS=*clang allows clang to interpret .s and .S differently without forcing -x assembler or -x assembler-with-cpp. Some builds like mogan that use xmake fails to parse AS variable with spaces. So I am not pursuing the change.

Therefore I propose to close this issue as won't fix.

-x assembler is optional, so how
about plain -c then?

My take is to not to force any command line argument when designate a compiler or assembler for compiling. That should be done by author's Makefile or build system. It has worked for a long time.

I let others to chime in first.

I let others to chime in first.

Will do.

My take is to not to force any command line argument when designate a compiler or assembler for compiling. That should be done by author's Makefile or build system. It has worked for a long time.

That's been my experience as well.
It's not the job of our build system to prescribe details of the toolchain down to the assembler flags.
If there are relevant differences between toolchains that a project wants to support it's a safe bet that the project will be handling the toolchain specifics itself, and if we do need to make fixes to that handling that is likely to be project specific and will be better served by an override in the build script, or a patch, as applicable.
There's unlikely to be a one size fits all solution in this case.

There's unlikely to be a one size fits all solution in this case.

That's exactly what was expected
to be otherwise. I.e. clang -c should
be fully gas-compatible.
So if this one doesn't regress (not
quite clear from this thread), I think
it makes sense to use that one, OR
just not to define AS at all. If AS is
not defined, then the build system
takes care of that.
Not the case when its wrongly defined...

I will leave up the rest of the team to decide whether to merge #23190 rebuild report. The gist is there's no difference.

The only other real world example I can find is Gentoo: https://github.com/gentoo/gentoo/blob/master/profiles/features/llvm/make.defaults

The drawback is to manually fix exotic build system for some packages which noted by gentoo/gentoo#27087 (comment)

Still, I found examples of AS=clang and pass -c separately as a argument more than AS=clang -c in the wild, contrary to author's claim of AS=clang is wrong.

AS=clang -c in the wild, contrary to author's claim of AS=clang is wrong.

OK, I re-checked if maybe
as reserves -c for compatibility.
It really looks like it does, but
when tracing with gdb, I've found
its actually interpreting -c as
--compress-debug-sections.
So you are not going to notice
the difference most of the time,
but its still not the right thing
to do.
So people who add -c later,
are walking across a thin ice.
--compress-debug-sections
is mostly harmless, but eventually
it will backfire somewhere.

Hmm, and actually, how about
simply adding "ASFLAGS=-c"?
If you ever switch AS, you will
also switch ASFLAGS, and the
problem solved?