-rtsopts is not respected with -dynamic on Windows
This gives rise to a large number of test failures of the kind
=====> stableptr001(dyn) 1297 of 2878 [4, 54, 8]
cd ./lib/should_run && 'D:/slave/stable/builder/tempbuild/build/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o stableptr001 stableptr001.hs -O -dynamic >stableptr001.comp.stderr 2>&1
cd ./lib/should_run && ./stableptr001 +RTS -K8m -RTS </dev/null >stableptr001.run.stdout 2>stableptr001.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
stableptr001.exe: Most RTS options are disabled. Link with -rtsopts to enable them.
*** unexpected failure for stableptr001(dyn)
The problem is that -rtsopts
relies on compiling a small C file with a definition for rtsOptsEnabled
, and linking this object into the executable, thereby overriding the default definition of rtsOptsEnabled
in rts/hooks/RtsOptsEnabled.c
. This works with static linking semantics and Unix dynamic linking semantics, but not Windows dynamic linking semantics. On Windows, the references to rtsOptsEnabled
in the RTS are statically bound to the default definition.
I think we ought to be able to solve it by generating a constructor function to initialise rtsOptsEnabled
, like this:
extern RtsOptsEnabledEnum __attribute__((dllimport)) rtsOptsEnabled;
static void __attribute__((constructor)) init(void)
{
rtsOptsEnabled = RtsOptsAll;
}
I tried this but didn't get it to work, so I'm leaving it for now.
Trac metadata
Trac field | Value |
---|---|
Version | 7.0.4 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | high |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |