Allow simulators to be compiled statically

[rpsene]

This change introduces a new variable, ENABLE_STATIC, to the build process, allowing the simulators to be compiled statically. This enhancement provides the flexibility to generate standalone simulators that are not dependent on shared libraries at runtime, which can be particularly beneficial for deployment in environments where managing dynamic libraries is challenging or for distributing simulators more easily.

[jrtc27]

• The commit message is all one giant subject line; please have a proper subject, and line wrap the body
• --as-needed, unless I’m missing something, has no effect on statically linked binaries, only dynamically linked ones
• -O1 seems entirely orthogonal to static linking, with its meaning linker-dependent. LLD defaults to 1, with levels ranging from 0 to 2, whilst according to the manpage GNU ld only has zero vs non-zero and says it only applies to shared libraries. If that’s true then this option makes no change to the level for LLD and has no change to the behaviour (since this isn’t a shared library) for GNU ld, so I question what purpose this is serving.

[github-actions[bot]]

Test Results

712 tests  ±0   712 :white_check_mark: ±0   0s :stopwatch: ±0s   6 suites ±0     0 :zzz: ±0    1 files   ±0     0 :x: ±0 

Results for commit be7acebf. ± Comparison against base commit 9602e3a5.

:recycle: This comment has been updated with latest results.

[rpsene]

• The commit message is all one giant subject line; please have a proper subject, and line wrap the body
• --as-needed, unless I’m missing something, has no effect on statically linked binaries, only dynamically linked ones
• -O1 seems entirely orthogonal to static linking, with its meaning linker-dependent. LLD defaults to 1, with levels ranging from 0 to 2, whilst according to the manpage GNU ld only has zero vs non-zero and says it only applies to shared libraries. If that’s true then this option makes no change to the level for LLD and has no change to the behaviour (since this isn’t a shared library) for GNU ld, so I question what purpose this is serving.

@jrtc27

The -Wl,--as-needed can help avoid linking against dynamic libraries that are not needed by the executable, which can still be relevant even when static linking. We can see this as safe option. The impact of -O1 is either non-existent or minimal, depending on the linker, and does not necessarily contribute to the optimization of static executables in a meaningful way, i agree with you here. Let's keep just the -static for simplicity for now, we can think about code size later, if need be.

[jrtc27]

Linking against what dynamic libraries? You’re creating a static executable. That’s my point; it is only meaningful when dynamic libraries are involved, but -static means they are not, by definition.

[rpsene]

Linking against what dynamic libraries? You’re creating a static executable. That’s my point; it is only meaningful when dynamic libraries are involved, but -static means they are not, by definition.

yep, I agree with you. My wording was not that clear. The new version of the PR just uses -static.

[rpsene]

@billmcspadden-riscv @jrtc27 is anything blocking the merge of this PR?

[jrtc27]

Well, your commit message is improperly formatted, but otherwise I don't think so beyond the continued dysfunction of this project.