Can I get the internal name of a package at runtime?

MarLinn monkleyon at
Sun Oct 15 14:37:17 UTC 2017

Hi Daniel,

that looks very interesting. I think it'll take some time to understand 
what's going on, but I already got some good parts. And even if I won't 
end up using it, this seems like a good way to learn some stuff. So 
thanks a lot!

For now I don't need the full power, so I think I'll take what I learned 
here and stick to a simple, hacky solution along the lines of Brandon's 
suggestions. Like enumerating object files in some specified directory, 
then mapping

     readCreateProcessWithExitCode (shell $ "readelf --symbols --wide " ++ path ++ " | grep closure | tr --squeeze-repeat ' ' | cut --delimiter=' ' --fields=9") ""

over them and z-encoding back and forth to discover what the heck I'm 
actually loading.
Elegant? No. Secure? No. Portable? …sufficiently. Works? …hopefully.

I got the feeling there is no good non-hacky way. Somewhere there's 
always some extra c code or something. I'm just glad my current goal is 
to just load object files, not compile user-supplied "scripts" into a 
running project or something.

So thanks again to you all!


On 2017-10-15 02:30, Daniel Gröber wrote:
> Hi,
> I think you might be interrested in my rts-loader package,
> particularly the [mkSymbol function](
> It should demonstrate how you can construct the symbol names for
> dynamic loading and how to coax the information needed out of Cabal,
> see the README and the rest of the source.
> --Daniel
> On Sat, Oct 14, 2017 at 09:59:03PM +0200, MarLinn wrote:
>> That sounds reasonable, but also like there *can not be* a way to obtain
>> that hash at runtime. And therefore, no way to discover the true package
>> name.
>> Which in turn makes discovery and loading of plug-ins a bit harder. Well, I
>> guess it's for a good reason so I'll have to work around it. Good to know.
>> Thanks for helping out!
>> Cheers,
>> MarLinn
>> On 2017-10-14 20:11, Brandon Allbery wrote:
>>> On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkleyon at
>>> <mailto:monkleyon at>> wrote:
>>>      So the "actual" package name seems to be
>>>      "Plugin-".
>>>      That leaves the random(?) characters behind the version number to
>>>      be explained.
>>> ABI hash of that specific package build, which is needed because
>>> compiling with different optimization levels etc. will change what part
>>> of the internals gets exposed in the .hi file for inlining into other
>>> modules; mismatches there lead to *really* weird behavior. (If you're
>>> lucky, it'll "just" be a type mismatch in code you didn't write, because
>>> it came from the .hi file. If unlucky, it compiles but dumps core at
>>> runtime.)
>>> -- 
>>> brandon s allbery kf8nh sine nomine associates
>>> allbery.b at <mailto:allbery.b at> ballbery at
>>> <mailto:ballbery at>
>>> unix, openafs, kerberos, infrastructure, xmonad
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at

More information about the ghc-devs mailing list