Can I get the internal name of a package at runtime?
monkleyon at gmail.com
Sat Oct 14 16:48:43 UTC 2017
That knowledge revealed that the "Ozi" part was actually the version number.
So the "actual" package name seems to be
That leaves the random(?) characters behind the version number to be
But at least now I can exploit the fact that a
"libHSPlugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe.a" file is generated. So if
I don't find the complete answer I still have a more portable way for
discovery than inspecting headers.
That's quite useful.
On 2017-10-14 18:01, Edward Z. Yang wrote:
> Hi MarLinn,
> The mangling name is "z-encoded". It is documented here:
> Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
>> I'm experimenting with plug-ins right now. I did manage to dynamically
>> load functions at runtime. The caveat: Something (cabal? ghc?) mangles
>> the package names. For example, to load a function called "theFunction"
>> from a module called "Callee" in a package "Plugin", I had to address it
>> via the name
>> O…K. Most parts of that are clear, and thanks for making my package
>> cooler by appending a "z", but who is this Ozi guy and why is he rapping
>> about modems? Without knowing Ozi, the only way I found to get at this
>> magic string is to manually look at the actual ELF-header of the
>> compiled module. While that might be a robust way, it seems neither
>> portable nor elegant.
>> The "plugins" library failed too, probably for the same reason. (Or it's
>> under-documented. Probably both.) The "dynamic-loader" library does
>> something via c, therefore no.
>> Which brings me to the question: Is there any way for a module to get at
>> its own internal package name? Or even at the internal name of an
>> external package? If not, can I somehow recreate the magic mangling at
>> runtime? At first I thought the functions in the "Module", "Name" etc
>> modules of GHC might help – but it seems I either need an existing Name
>> (that I have no idea how to get) or I have to create one (with no idea
>> what magic mangler to call).
>> I'm asking this question here rather than on café as I feel that if
>> there is a solution, it's probably buried in the details of GHC.
>> Thanks for any suggestions,
More information about the ghc-devs