>      > Adding -ffunction-sections -fdata-sections to defaults can help considerably in producing smaller binaries, and is not the default.
>      > Linking with -Wl,--gc-sections helps a lot and is not the default
>
>     These OTOH are interesting I know that e.g. uboot combines these and it helps a lot to get smaller binaries,
>     and this should help with RAM size too, since if a page of a binary contains mostly unused things and 1 symbol
>     which is actually used it will still get paged in.
>
>     Can you perhaps start a new devel list thread about just this ? Maybe with some binary size numbers for
>     some apps / libs build with and without these options?
>
>
> It's pretty well documented in various articles, e.g.:
> https://wiki.wxwidgets.org/Reducing_Executable_Size
> It also covers how much difference -Os can make.

Interesting, thank you for that link.


>      > Extensive stripping seems to already be the default (--strip-unneeded, removal of .comment and .note sections)
>      >
>      > 2) Runtime condiguration
>      > Default stack size is 8192 (ulimit -s). This unnecessarily eats a considerably amount of memory. I have yet to see anything that actually experiences problems with 1M.
>
>     Actually ulimit -s is the *maximum* stack size, I'm pretty sure the stack will start much smaller and
>     grow dynamically. So changing this is not saving any RAM and it will makes apps which do have high
>     stack usage crash when they hit the new lower limit.
>
>
> Either way, it makes a noticeable difference to memory consumption on a very memory constrained system without any other obvious adverse effects.

Interesting unless I'm reading the manpage wrong, "ulimit -s" sets the maximum stack-size.
Maybe that also influences the initial sizing of the stack ?

Can someone who knows more about this shed some light on this? Is there a way to go with
a smaller initial stack-size without changing the maximum size?