This seems fine to me (and the generally correct way to handle size_t and ssize_t comparisons) but I'd like to see what @asomers thinks.

I find it quite surprising that this would just be broken in the upstream build; is it possible this is an artifact of our bespoke build process? Presumably the Implement the POSIX strerror_r API in terms of the GNU strerror_r section has to be used on GNU systems?

admbugs 1021

Is assfail actually used? I see a dtrace_assfail in dtrace code. (Didn't check the others.)

Bora was a co-op student at the time of this submission, and I don't believe is using FreeBSD any longer.

A couple of grammar edits which I hope are correct and clarify things

I don't really like this being done for x86 only, but I'd rather have it at least here for now and we can follow up with other architectures

I think we want ()s
Considering uses like MIN_T(int, a - b, a + b)

See also https://github.com/llvm/llvm-project/issues/138272

These seem a bit silly (shrug)

A couple of lines maybe need wrapping though

Make a new usr.bin/clang/toolchain/Makefile to put the LLVM binutils symlinks in the toolchain package when LLVM_BINUTILS is set.

Use relative not absolute symlinks

Oh we should probably drop the ${BINDIR} from the link targets

As discussed w/ @ivy, I think the better path is to:

1. Move the unprefixed links to SYMLINKS
2. Move the unprefixed symlinks into their own Makefile with PACKAGE=toolchain (prefixed tools will move back to the clang package).
3. Add a conditional dependency to the toolchain package on clang

In D55693#1274557, @dim wrote:

I'm fine with this, but what is the motivation? Easier packaging?

what do you think?

SYMLINK to the correct llvm-prefixed tool

Right now c++filt, objcopy, readelf, addr2line are either in the clang or toolchain package, depending on LLVM_BINUTILS.

one way i think this could cause problems is once we add pkgbase depends support to ports. say there's a port that specifically requires "llvm-objcopy", which package should it depend on to get that?

i'm not sure if i like this; it seems odd that the same binary can move between packages like that. is the rationale here to avoid bringing in LLVM libraries as a dependency of toolchain when LLVM_BINUTILS is disabled?

Fix up llvm-cxxfilt

Oh I see @delphij fixed the build in 8dd28e13e41b6200e58d6e99981ff8323cff3711

I observed the same failure with 9cea0f0be79d reverted and am trying to figure out where this came from.

Would it make sense to test this somewhere on top level, and refuse to start the buildworld and buildkernel?

krb5 build failures have been occurring for a while afaik, e.g. PR293258? 9cea0f0be79d should be a no-op since the now-removed (portions of) if conditions were always true .if ${${X_}LINKER_TYPE} != "bfd" || ${${X_}LINKER_VERSION} > 21750 and the part of .if ${${X_}LINKER_TYPE} == "bfd" && ${${X_}LINKER_VERSION} > 21750 after &&

I've reverted d99f16276e06736ceff9ea3ae5a1ac09135bcfdc for now. Let's get this change fixed up and in to src and we can then reapply it.

I guess that means build-id and ifunc no longer need a feature check and we can count on them being available.

As an aside, a next step could be to remove .if ${${X_}LINKER_TYPE} != "bfd" || ${${X_}LINKER_VERSION} > 21750 as I think we aren't concerned with BFD ld 2.17.50 any longer.

src.conf.5 will be regenerated upon commit