Mk/Uses/kmod.mk: Set MACHINE and MACHINE_ARCH to handle cross-building

[jrtc27]

Summary

Commit d7511b9d0074 ("Mk/bsd.port.mk: Add __MAKE_CONF=${NONEXISTENT} to
WRK_ENV") stopped having sub-makes pull in Poudriere's make.conf that
sets MACHINE and MACHINE_ARCH. As a result builds of kernel modules
think they're for the native architecture, which leads to the kinds of
breakage one would expect. Pass them on in the environment to fix this.
This does feel like a bit of whack-a-mole though, and probably
MACHINE(_ARCH) should be handled more globally, given /nxb-bin's bmake
reports native values.

Fixes: d7511b9d0074 ("Mk/bsd.port.mk: Add __MAKE_CONF=${NONEXISTENT} to WRK_ENV")

[tijl]

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

[jrtc27]

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.

[jrtc27]

In D46502#1060031, @jrtc27 wrote:

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.

Ping?

[tijl]

In D46502#1060031, @jrtc27 wrote:

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.

Because make.conf is injected into every Makefile out there everything you put in it has unknown consequences. The only way to contain that is to put everything in make.conf behind an .if block like .if !empty(.CURDIR:M/usr/ports/category/port/work/*). This isn't documented very well.

You mentioned any breakage would be the user's fault and I agree but the problem is that users that modify make.conf and run into problems tend to forget about their changes and submit bug reports without mentioning them. That leaves port maintainers scratching their heads. So it's the user's fault but it's the port maintainers that pay the price with their time spent trying to figure out what's going on. I'm all for foot shooting options but not when they let users shoot into other people's feet.

You should not have to use make.conf like that. If an upstream Makefile is configurable then the port Makefile should replicate that and you can configure the port using make.conf. You can submit a bug if that's not the case.

I've submitted a patch for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281674.

[jrtc27]

Cc @bdrewery for poudriere things...

In D46502#1066063, @tijl wrote:

In D46502#1060031, @jrtc27 wrote:

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.

Because make.conf is injected into every Makefile out there everything you put in it has unknown consequences. The only way to contain that is to put everything in make.conf behind an .if block like .if !empty(.CURDIR:M/usr/ports/category/port/work/*). This isn't documented very well.

You mentioned any breakage would be the user's fault and I agree but the problem is that users that modify make.conf and run into problems tend to forget about their changes and submit bug reports without mentioning them. That leaves port maintainers scratching their heads. So it's the user's fault but it's the port maintainers that pay the price with their time spent trying to figure out what's going on. I'm all for foot shooting options but not when they let users shoot into other people's feet.

You should not have to use make.conf like that. If an upstream Makefile is configurable then the port Makefile should replicate that and you can configure the port using make.conf. You can submit a bug if that's not the case.

Well that's how it's worked for years and how poudriere works. Playing whack-a-mole and arbitrarily picking which subset of make.conf to pass on sounds like a terrible idea to me. There will be others. Just because users can shoot themselves in the foot with a feature doesn't mean we should disable it, *especially* when it is *the* way things are made to work with poudriere.

I've submitted a patch for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281674.

Well that doesn't even do MACHINE, which is important, otherwise you'll end up with MACHINE not matching MACHINE_ARCH, which breaks things. You can't in general just set one; that's a custom feature of the src tree's Makefile.

[tijl]

In D46502#1066069, @jrtc27 wrote:

I've submitted a patch for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281674.

Well that doesn't even do MACHINE, which is important, otherwise you'll end up with MACHINE not matching MACHINE_ARCH, which breaks things. You can't in general just set one; that's a custom feature of the src tree's Makefile.

The way to override machine and machine_arch is to set UNAME_m and UNAME_p environment variables and poudriere does that. MACHINE and MACHINE_ARCH are make's own internal representations of machine and machine_arch and it should look at UNAME_m and UNAME_p to define those built-in variables. For MACHINE it already does so, indirectly, because it calls uname(3) to obtain machine and that returns UNAME_m when set. That's why I left it out of the patch. For MACHINE_ARCH make cannot use uname(3) because it does not return machine_arch. It calls sysctl("hw.machine_arch") instead. To fix this, either uname(3) needs to be extended to support machine_arch, returning UNAME_p when set, or make should look at UNAME_p directly.

Poudriere is a driver for the ports tree and the ports tree does not use MACHINE and MACHINE_ARCH anywhere, so it is strange that poudriere has to set these variables. This is a make bug and it only affects MACHINE_ARCH. There's no whack-a-mole or arbitrarily picking subsets of make.conf.

[jrtc27]

3154506a168d8188fe06f252e070b394b6581db3