We can't use `ulimit -s` to limit stack size on Windows. Even though Bash
accepts `ulimit -s` and the numbers change it has no effect and is not passed
to child processes.
(See https://public-inbox.org/git/alpine.DEB.2.21.1.1709131448390.4132@virtualbox/)
Instead, set it when building the test executable, following, a suggestion from
@stefantalpalaru.
https://github.com/status-im/nimbus-eth1/pull/598#discussion_r621107128
To ensure no conflict with `config.nims`, `-d:windowsNoSetStack` is used. This
proved unnecessary in practice because the command-line option is passed to the
linker after the config file option. But given we don't have an automated test
to verify linker behaviour, it's best not to rely on the option order, neither
how the linker treats it, or whether Nim will always send them in that order.
Testing:
This has been verified by using a smaller limit. At 200k, all `ENABLE_EVMC=0`
OS targets passed as expected, and all `ENABLE_EVMC=1` OS targets failed with
expected kinds of errors due to stack overflow, including Windows.
(400k wasn't small enough; 32-bit x86 Windows passed on that).
Signed-off-by: Jamie Lokier <jamie@shareable.org>
* switch to chronos metrics, remove insecure
See https://github.com/status-im/nimbus-eth2/pull/2468
also fixes pcre linking for real, and adds some random build flags that
help nimbus-eth2 stay afloat
* fix help
* don't omit frame pointers on windows
* bump vendor/nimbus-build-system
- add the Nim compiler header to the Nimbus header
- also support the USE_LIBBACKTRACE env var
* "go-checks" target no longer available
Ștefan Talpalaru
Jamie Lokier
Jacek Sieka