Re: conditionals for platform-specific MAKE_ENV options

[Greg Troxel <gdt%lexort.com@localhost>]

Brook Milligan <brook%nmsu.edu@localhost> writes:

> I am trying to make a package that has the following notes about compiling:
>
> - If you see compilation errors, try make sse2only=1 to disable SSE4 code.
>
> - It also works with ARM CPUs supporting the NEON instruction sets. To
> compile for 32 bit ARM architectures (such as ARMv7), use make
> arm_neon=1. To compile for for 64 bit ARM architectures (such as
> ARMv8), use make arm_neon=1 aarch64=1.

This sounds like it might be an upstream bug, but there are differing
opinions about build environment and binary portability.

I am guessing there is assembler involved.

The basic issue is that NetBSD has a notion of minimum CPU for an
architecture and by default defines the toolchain to build for that CPU.
That almost always results in the binaries running on every system that
can run that arch/machine_arch of NetBSD, even if the machine you build
the binary on has more features.  So compile-time CPU feature detection
is basically a bug.  Run-time on the other hand is not; openssl does
this on arm.

For the i386 port, I am 95% sure the target is still i486.

For the evbarm port (32 bit flavors), we have a number of MACHINE_ARCH
targets.  For the aarch64 flavor of the evbarm port, I think we only
have one (v8) so far.

There is a notion of compiler flags to set -mfoo to tune the instruction
set for a different set of CPUs, and people sometimes do that on i386 to
enable newer instructions at the risk of not running on their strategic
stockpile of 486s.  I do not hear about this on amd64 so much, where the
oldest CPU arch has more features.  On arm, people tend to use
earmv7hf-el builds on RPI3, or at least earmv6hf-el, and thus it's
pre-optimized.

In your case, it seems the package has aggressive defaults that won't
run on all flavors of the MACHINE_ARCH it's being built on.  Or perhaps
somethign else, since it's talking about "compilation errors".

> I am assuming that I should include a conditional based upon
> MACHINE_PLATFORM to set MAKE_ENV so that (at least some of) these
> cases are handled.  However, I am not sure what the conditional should
> be.  Thus, I have several questions.
>
> - I know that SSE4 was introduced a long time ago, but are there any
> relevant platforms that should still use the sse2only=1 option?

Here, it comes down to asking if any CPU that can run the MACHINE_ARCH
lacks that feature.  If there is one, then sse2only should be enabled
always, unless the user sets an option.  We have a bunch of options
already; it might be good to just use a common name for "allow packaegs
to use this CPU feature".

The other approach is to just not worry and accept that this package
will fail to run on an older computer, and see what happens with
reports.  That's a little lame, but it likely is good in terms of total
time used up among you and all users.

What are you building on, and what happens?

> - What is the best way to handle conditionals for the two ARM
> architectures mentioned above?

MACHINE_ARCH matching earmv8 is easy to test for.  You can probably turn
on neon for earmv6hf-el and higher.  If you get it not quite right and
somebody has to tweak it, I don't see that as a big deal.