Page MenuHomeFreeBSD

retire SHARED_TOOLCHAIN knob
ClosedPublic

Authored by emaste on Aug 1 2023, 12:53 PM.
Tags
None
Referenced Files
F102556531: D41266.diff
Thu, Nov 14, 12:43 AM
Unknown Object (File)
Fri, Nov 1, 4:58 AM
Unknown Object (File)
Sun, Oct 27, 1:56 AM
Unknown Object (File)
Oct 2 2024, 6:02 AM
Unknown Object (File)
Oct 2 2024, 5:46 AM
Unknown Object (File)
Sep 26 2024, 11:59 PM
Unknown Object (File)
Sep 24 2024, 2:35 PM
Unknown Object (File)
Sep 22 2024, 1:55 PM

Details

Summary
Toolchain components were historically statically linked.  They became
normal dynamically linked executables in commit 6ab18ea64d19.  There is
no need to keep a special case build option for the toolchain; users who
want statically linked toolchain (or any other) components can use the
existing NO_SHARED knob.

Relnotes:       Yes
Sponsored by:   The FreeBSD Foundation

Diff Detail

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

Event Timeline

emaste added a subscriber: sjg.
emaste added inline comments.
share/mk/local.sys.dirdeps.mk
68

Or, should this become NO_SHARED=yes?

We could extend/use @cperciva's REQUIRED_OPTIONS functionality (b908f6c45e0202deb86fc9bde1b07212924c05fc) to facilitate the knob deprecation, but IMO it is unnecessary.

The time is indeed ripe for this setting to go, but the "toolchains can be a pain" line is maybe a little worrying? @sjg put it in, in rG0244ab1f26bcc, but that was a looooong time ago...

This revision is now accepted and ready to land.Aug 1 2023, 5:51 PM

The "toolchains can be a pain" comment predated the addition of NO_SHARED_TOOLCHAIN there; the commit message says "(for now) non-shared toolchain when building for host". It doesn't explain what was actually broken but the "for now" suggests it wasn't intended to be permanent. I'd be fine with going ahead with this and revisiting host toolchain build if it proves necessary, but either way I'll give @sjg some time to review/comment before committing.

sjg added inline comments.
share/mk/local.sys.dirdeps.mk
68

I think it can just go away, if I discover otherwise I can fix it ;-)

This revision was automatically updated to reflect the committed changes.