Support for static binaries via the menu?

[rubyFeedback]

The README mentions LDFLAGS="--static", so strictly speaking my request here is not necessary.

However had, in the old busybox interface (make menuconfig), one option was to compile everything in a static binary. So this is just a convenience option perhaps, if one entry could be added there where we can compile statically. I often forget setting LDFLAGS, so having this in the main menu would be nice, just like busybox. At any rate, thank you for reading this request.

[landley]

On 1/26/25 15:53, rubyFeedback wrote: The README mentions LDFLAGS="--static", so strictly speaking my request here is not necessary.

This is a repeat of issue #491. You can make persistent local environment changes in the "configure" file at the top level, try LDFLAGS+=" --static" (yes with the space, that way it works with any existing variable contents) right after the comment about the default file not doing anything with LDFLAGS. Static linking on glibc is extensively broken, because Ulr̈ich Drepper hated it, and wrote his own manifesto against it at https://www.akkadia.org/drepper/no_static_linking.html (which multiple other people debunked ala https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/) and Ulric̈h was glibc's maintainer before the mortgage crisis, when he bogged off to work at the Bank of Evil and got replaced by a committee that does its best to never actually make decisions, which means they don't fix anything without a bugzilla entry that's gone thorough the Full Vogon Process (including the "buried in soft peat for three months and recycled as firelighters" part which is harder to do digitally). Undoing the terrible design decisions of a Red Hat employee would be admitting Red Hat made a mistake, so... The FAQ mentions static linking in several places (such as https://landley.net/toybox/faq.html#cross1) but doesn't have a dedicated entry on the topic, and maybe it should. But I'm not sure what it should say (it could go on for a VERY LONG TIME), nor am I sure I could maintain a "professional tone". (Cutting and pasting the previous paragraph into the FAQ would be easy, but... eh.) I also admit part of my reluctance to add a config toggle (other than "how you build the binary is the toolchain's problem, it's a layering violation having the config system know or care about the difference between MacOS mach-o binaries and nommu binflt format") is that I get enough "allyesconfig is broken" bug reports without adding "dns lookups don't work, ls isn't showing usernames" and so on from glibc having gated vital functionality behind dlopen(). Right now menuconfig doesn't know about ASAN (it's an environment variable), install vs install_flat are different make targets rather than a config entry, and building on a mac without homebrew uses a wrapper script (scripts/prereq/build.sh) instead of a config entry. Speaking of, I have a TODO item to collate CONFIG_WGET_LIBTLS, CONFIG_TOYBOX_LIBCRYPTO, and CONFIG_TOYBOX_LIBZ into a single toggle saying to use internal implementations even when library versions of things like libz are available in the build environment. It's on my todo list next to "should disable recursive execution be flipped? Switching a config symbol ON to switch stuff OFF is weird, but needing to enable symbols to get default behavior is also weird..."

[enh-google]

Speaking of, I have a TODO item to collate CONFIG_WGET_LIBTLS,
CONFIG_TOYBOX_LIBCRYPTO, and CONFIG_TOYBOX_LIBZ into a single toggle
saying to use internal implementations even when library versions of
things like libz are available in the build environment.

note that you might only have some subset of the libraries available but still want to use them -- android has the latter two, for example, but not the former -- so even if the user-visible knob is just "yes"/"no", internally you'll still need to cope with the different possible combinations.

(you'd have noticed this anyway, since libtls and libcrypto are mutually exclusive in wget :-) )

[landley]

On 1/27/25 08:47, enh-google wrote: note that you might only have some subset of the libraries available but

still want to use them -- android has the latter two, for example, but It would have to autodetect what's available and use the builtins for the rest. I wouldn't be doing it to simplify the plumbing, it would be to simplify the user experience of people running menuconfig. (Although between __has_include() header probes and the existing --as-needed library dropout logic, it might still wind up simpler anyway?)

[enh-google]

On 1/27/25 08:47, enh-google wrote:
It would have to autodetect what's available and use the builtins for
the rest. I wouldn't be doing it to simplify the plumbing, it would be
to simplify the user experience of people running menuconfig.

yeah, that makes sense.

(Although
between __has_include() header probes and the existing --as-needed
library dropout logic, it might still wind up simpler anyway?)

that would certainly work for Android and let me just delete stuff. i don't know if there's anyone who has a library but doesn't want toybox to use it? (or whether you should care enough to support them even if they do exist. they can always carry a local patch.)

[landley]

i don't know if there's anyone who _has_ a library but _doesn't_ want toybox to use it? (or whether you should care enough to support them even if they do exist. they can always carry a local patch.)

There's basically two use cases: the self-bootstrapping one where you want NO external dependencies (countering trusting trust, internal testing, simplified cross compiling, understandable minimal system, etc) and the "if a supported helper is present use it" case. Micromanaging a halfway state between those two doesn't appeal, so one config switch. The same way CONFIG_TOYBOX_NORECURSE doesn't say _which_ builtins to call internally without checking the $PATH, just whether or not to do that at all.