Page MenuHomeFreeBSD

Makefile.inc1: Only copy locales to INSTALLTMP on FreeBSD
ClosedPublic

Authored by ivy on Apr 28 2026, 3:29 AM.
Tags
None
Referenced Files
F158267721: D56677.id.diff
Sat, May 30, 2:29 PM
Unknown Object (File)
Wed, May 20, 7:54 AM
Unknown Object (File)
Mon, May 18, 9:08 AM
Unknown Object (File)
Mon, May 18, 9:04 AM
Unknown Object (File)
Sun, May 17, 12:54 PM
Unknown Object (File)
Sun, May 17, 7:08 AM
Unknown Object (File)
Sun, May 17, 7:04 AM
Unknown Object (File)
Sat, May 16, 12:00 AM
Subscribers

Details

Summary

Makefile.inc1 copies locales to ${INSTALLTMP} to avoid issues when
running make installworld on a live system. However, this can break
on non-FreeBSD systems, e.g. on openSUSE where /usr/share/locales
has mode 0555, which means after we copy it, we can't delete it,
so the build fails.

Since this functionality is only useful when installing over a
live system, disable it when the build host is not FreeBSD.

Sponsored by: https://www.patreon.com/bsdivy

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ivy requested review of this revision.Apr 28 2026, 3:29 AM
Makefile.inc1
1484–1485

There's a PATH_LOCALE setting in one of the *ENV that should get similar treatment- I would suspect the variable is pretty specific to our libc (and Dragonfly, maybe Illumos and macOS), but probably better to be clear.

I'd also be supportive of your other proposal to avoid it if DESTDIR != /, though I don't know if you dismissed that idea entirely. I don't feel strongly about it...

only set PATH_LOCALE on FreeBSD

Makefile.inc1
1484–1485

i went through a couple of approaches here; i think ideally we should disable this entire feature, even on FreeBSD, when we aren't doing a live installworld, but that's a larger and more risky change... this is the least invasive change that fixes the Linux build in the mean time.

kevans added inline comments.
Makefile.inc1
1484–1485

Yeah, fair enough!

This revision is now accepted and ready to land.Apr 28 2026, 2:03 PM

I think this is fine for now. I'd be happy to see DESTDIR-based changes later on.