CVS Repository/ src/ gnu/ usr.bin/ binutils-2.17/ Makefile.bsd-wrapper

Use -std=gnu89 to fix the build with clang-16

This is ancient GNU software that tends to break whenever clang adds
more warnings about deprecated features in new languages versions or
turns them into errors.  Using -std=gnu89 (the defaults for base-gcc)
for those packages means we'll probably avoid most new warnings, errors,
and possible miscompilations when updating clang.

ok robert@

Recommit the switch to use llvm-strip on architectures that use ld.lld.

ok naddy@, sthen@

Revert previous commit (but leave the man page around); llvm-strip behaves
differently on files that are hardlinked and this is tripping up ports.

requested by naddy@

The binutils strip damages GNU_RELRO on binaries linked by ld.lld on at
least amd64.  Fix this by switching to the llvm strip on architectures
that use ld.lld.

ok deraadt@

use llvm-ranlib where llvm-ar is used so that they are in line with each
other

binutils-2.17 does not have ld or gas available for the aarch64, powerpc64, or
riscv64 family of platforms, so we don't try to build there.

However we mis-nested the arch check, causing some unintended side effects,
most notably installing binutils-2.17's ar(1) which overwrote the
intended llvm-ar(1).

Fix the if nesting so it only applies where intended.

tested on aarch64 by me, powerpc64 by gkoehler@, and riscv64 by jca@

OK miod@ robert@ gkoehler@ jca@

Avoid errors about clang13-only options here, to ease transition

As pointed out by deraadt@ we can do better than ask people to follow
instructions.  Note that you still need an up-to-date clang if you
update your kernel Makefiles, as those use clang13-only options.

Also -Werror doesn't bring much in binutils context.  It's an outdated
codebase with lots of warts, which frequently breaks due to -Werror
during clang updates.

"This is the right fix" deraadt@

Disable a few warning flags that were introduced and enabled by default
with LLVM 13.

add llvm-ar(1) to the build with its two dependencies libLLVMDlltoolDriver
and libLLVMLibDriver;

switch LLD_ARCHs to llvm-ar(1) by skipping the installation of binutils' ar(1)
and linking llvm-ar(1) to ar(1)

tested on amd64, i386, arm64 and mips64

ok patrick@, kettenis@

correct riscv64 blocks
discussion with espie kettenis jsg

riscv64 binutils 'support'
Enable just enough of binutils to be a functional compilation system
with llvm doing the heavy lifting.
With corrections suggested by reviewers.
ok jsg@ kettenis@

Initial set of changes to build powerpc64 toolchain.

Disable PIC/PIE for powerpc64 for now.

avoid build race condition: our make has an "expensive job" heuristic
which means we do stop creating other jobs as soon as we run something looking
like "make" to avoid unwanted recursion, so you would never hit that.

But in binutils-2.17, the developers changed all/info to do recursive makes
with some of the same dependencies.  Calling both at the same time becomes
an obvious race, and should be fixed for no other reason than correctness.

okay guenther@

a few depend:-related thingies that were still in.

okay millert@, tb@

stop using the moribund MLINKS bsd.man.mk feature;
no functional change intended;
OK millert@

Remove -S from install commands

As of usr.bin/xinstall/install.c revision 1.68, -S is a no-op and
install(1) will always create files safely, thus clean the option usage
from the tree.

Diff from Lauri Tirkkonen <lotheac at iki dot fi>, thanks.

Pass CC/CFLAGS/LDFLAGS to the configure script.  ok millert@

Add infrastructure to install lld as the default linker.  The old GNU linker
will be installed as /usr/bin/ld.bfd on supported systems.  This allows
users to fall back on the old linker by using the -fuse-ld=bfd option on
systems where lld is the default linker.

Switch armv7 to use lld as the default linker.  On arm64 we already use lld
as the default linker.  Other platforms will keep using the GNU linker for
now.

ok patrick@, deraadt@, phessler@

destroy lint remnants.
okay millert@ deraadt@

Go back to only specifying --target when building cross.

The OpenBSD triple includes the OpenBSD version.  When this recently
changed binutils started building prefixed tools when moving to a new
OpenBSD version which isn't what we want.

ok kettenis@

Stub out aarch64 support and avoid building gas and ld on this architecture.

ok mpi@, patrick@

Fix ownership for install on a noperm filesystem.
joint work with tb

Use ${INSTALL} instead of install, like in all the other Makefile's.
ok guenther

Install programs with ${INSTALL_STRIP} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE}
Install info and data files with -o ${DOCOWN} -g ${DOCGRP} -m ${NONBINMODE}

Prompted by natano@
Tweaks and oks deraadt@ natano@

ELF_TOOLCHAIN bye bye.

Sync to ../binutils/Makefile.bsd-wrapper rev. 1.75:
eplace a comment asking for a particular order to build stuff in
by actual make rules to enforce that order.
While here, correct the MANDIR which must no more contain "cat".

Let platforms configured to use binutils 2.17 still recurse into the binutils
2.15 directory, but only to build gdb.
ok deraadt@ espie@

Replace the list of platforms enabled (or not) to build the whole binutils
with a test of ELF_TOOLCHAIN provided by bsd.own.mk.
No functional change.

Add support for PIE-by-default in both ld and gcc.  This is a completely
different approach than the one taken in kurt@'s original diff, but deemed
better after discussion and diff exchange with kettenis@ and matthew@.

Lots of feedback by kettenis@ and matthew@, prodding and encouragement by
deraadt@.

ok kettenis@ matthew@

Sync to ../binutils/Makefile.bsd-wrapper rev. 1.76:
Always install addr2line(1), objcopy(1), and readelf(1) manuals,
even on architectures with !ELF_TOOLCHAIN && !USING_NEW_BINUTILS.
Such architectures do not yet exist, but both symmetry
and fixing potential future issues early  are good ideas.
ok jsing@

My merges of miod's binutils-2.17 WIP code with my changed necessary to get
somewhere with it building on arm/ia64. much pressure pirofti@ deraadt@

A first attempt at merging our local changes and fixes into the 2.17 codebase.
ld(1) needs a lot more work, as the upstream code evolved significantly since
2.15, mostly due to changes in PIE binaries layout, and we had already
diverged significantly to implement W^X.