build: let the environment override MACOS_TARGET by prakashrj · Pull Request #61 · tailscale/libtailscale

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

prakashrj · 2026-08-30T18:14:31Z

MACOS_TARGET := 15.0 is a simply-expanded assignment, so an environment variable does not override it. MACOS_TARGET=14.0 make c-archive builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only make MACOS_TARGET=14.0 c-archive works.

Measured

make -n, GOOS=darwin, against this Makefile:

	before	after
`MACOS_TARGET=14.0 make …` (env)	15.0	14.0
`make MACOS_TARGET=14.0 …` (command line)	14.0	14.0
default, nothing set	15.0	15.0

?= fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it.

Why it's worth fixing

The failure is quiet in a way that matters for this particular variable. Nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects don't actually support. On macOS the only signal is an ld: warning: object file … was built for newer 'macOS' version, which is easy to lose in build output — and otool won't catch it either, since it reports the number the binary claims.

Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo.

It's also the same knob #60's "Aside" points at: if the project lowers its own deployment targets, whoever does that is likely to reach for the environment variable first.

Not touched here

The comment above the line still says the wrapper requires macOS 15.0 features. That's a separate question and depends on #60, which measures macOS 14.0 as buildable once the listener API is gated — happy to follow up there if that lands.

`MACOS_TARGET := 15.0` is a simply-expanded assignment, so an environment variable does not override it. `MACOS_TARGET=14.0 make c-archive` builds 15.0 and reports success — you set the floor, make agrees, and you get the old one. Only `make MACOS_TARGET=14.0 c-archive` works. Measured with `make -n` against this Makefile, GOOS=darwin: before after env override 15.0 14.0 command-line 14.0 14.0 default 15.0 15.0 `?=` fixes the environment case and changes nothing else: a command-line override still wins, and the default is untouched for anyone not setting it. Found while lowering the macOS floor of a TailscaleKit.xcframework built from this repo. The failure is quiet in a way that matters here — nothing warns, the build succeeds, and the resulting binary is stamped with a floor its Go objects do not actually support. On macOS the only signal is an `ld: warning: object file ... was built for newer 'macOS' version`, which is easy to lose in build output. This is the same knob tailscale#60's "Aside" points at: if the project lowers its own deployment targets, whoever does it is likely to reach for the environment variable first. Not touched here: the comment above the line still says the wrapper requires macOS 15.0 features. That is a separate question and depends on tailscale#60, which measures macOS 14.0 as buildable once the listener API is gated.

This was referenced Aug 30, 2026
libtailscale: MACOS_TARGET cannot be overridden from the environment, so a lowered macOS floor is silently ignored tailscale/tailscale#21044
Closed
docs: record libtailscale#61 and its tracking issue indiagrams/tunnelless#59
Merged

barnstar approved these changes Aug 31, 2026
View reviewed changes

barnstar merged commit 59d4bb8 into tailscale:mainAug 31, 2026
1 check failed

prakashrj mentioned this pull request Aug 31, 2026
docs: #58, #60 and #61 merged upstream — and what that does not yet mean indiagrams/tunnelless#62
Merged