Symbol names not matching library assumptions

[fluffynukeit]

The source for the lookupSymbolinternal function makes certain assumptions about the naming convention of symbols in the module .o file. However, my symbols don't match this convention (I don't know why): readerzmmabelzm0zi1zi0zi0_Mabel_hdf5Root_closure The symbol is prefixed by the package name, and I don't believe there's a way for me to structure my plugin paths or module names to get dynamic-loader to use this name for this symbol.

What would be useful is an "escape hatch" function that lets the user specify the symbol name directly. I'll add one and submit a PR.

[fluffynukeit]

I implemented this in fluffynukeit/dynamic-loader@6932206, but I am having difficulty testing it on anything but the most basic of functions. For instance, getting a symbol for top-level String is quite easy.

If I try to actually load my plugin, I start encountering a lot of issues. If I load the .o file of the plugin, I get unknown symbol `base_GHCziInt_I32zh_con_info'. If I try to load my libHSbase*.so file with loadPackage, I get an error that it's not a .o file. Instead I try loading with addDLL, but then I encounter what appears to be a cyclic dependency between base, ghc-prim, and the RTS, so trying to load them in any order doesn't work.

Note that the above is testing with compilation to an exe. I also tested with ghci, and in doing so got a segfault when I try to run the function I loaded (loading a String and printing it works fine). The segfault caused ghci to quit instead of print --Segmentation Fault

So I haven't created the pull request because I'm not certain this problem is outside the changes.

[fluffynukeit]

I was not able to figure the issue out, but I believe the issue is on my side, and the function implementation is correct. #4 is the associated pull request.