having to call hs_add_root(__stginit_Foo) is a bit of a pain

For C code calling C functions exported from Haskell code, it has to jump through a couple hoops first. The call to hs_init() is fair enough and is specified by the FFI, however GHC also makes us call:

hs_add_root(__stginit_Foo);

for the top level Haskell module that exports the function we're interested in. If there are multiple such modules and they don't depend on each other then presumably we have to call them all.

Doing this is a bit annoying. It's not just that we have to call it, but we have to work out which symbols we need exactly. Are there any ways we could automate it? If the __stginit_* functions are really cheap then can we just have them called as constructor functions using gcc's __attribute__ ((constructor)) system. If they're slightly more expensive then perhaps they could be registered in a constructor and called by hs_init(). Or can we have them run lazily, eg have the exported C functions check that the module they're in has been initialised.

Trac metadata

Trac field	Value
Version	6.10.2
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (FFI)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added FFI Tfeature request Trac import labels

Generating constructor functions in Haskell modules would be a bit tricky, because we'd have to generate code that has the C calling convention, and neither the NCG nor the mangler knows how to do that.

Something along the lines of the last method (have the exported C functions check that the module they're in has been initialised) might be possible. But we have to be careful not to add too much overhead to the call-in path.

I'll think some more about this.

changed milestone to %6.12.1

removed milestone

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

I recently ran into this issue when building a shared library with a c-interface. A hand-built library (module CInterface, no package) would link fine. A cabal-built library (package test-0.0) would fail with:

./libHStest-0.0-ghc6.12.1.so: undefined reference to `__stginit_CInterface'

After some help from duncan:

> nm libHStest-0.0-ghc6.12.1.so | grep stginit
...
00004570 T __stginit_testzm0zi0_CInterface
00004500 T __stginit_testzm0zi0_CInterface_dyn
...

So it turns out that the package name and version are embedded into the symbol. This necessitates manually updating the c source files whenever the package version is incremented. The error is additionally confusing since the manual states that ghc will automatically export __stginit_Foo, and also since it isn't even reported until the consuming application is linked.

Some way to have ghc take care of this automatically would be much appreciated!

Yes, the package name and version are omitted when this is the main pacakge (the default). It is possible that different packages use the same module name, so it's not possible to use the __stginit_Foo form when the modules are being built as part of a package.

We'll put some thought into how to do the initialisation automatically.

mentioned in issue #4387 (closed)

changed milestone to %7.2.1

changed weight to 7

Trac metadata

Trac field	Value
Priority	normal → high

mentioned in issue #4417 (closed)

mentioned in issue #4519 (closed)

See also #4417 (closed).

assigned to @simonmar

I have work-in-progress to fix this.

mentioned in commit a52ff761

closed

Done; see changeset:a52ff761

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in commit a92ff5d6

added Phigh label