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

MarLinn monkleyon at gmail.com
Sat Oct 14 16:48:43 UTC 2017


Hi Edward,

thank you.
That knowledge revealed that the "Ozi" part was actually the version number.

So the "actual" package name seems to be 
"Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
That leaves the random(?) characters behind the version number to be 
explained.
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.

Cheers,
MarLinn


On 2017-10-14 18:01, Edward Z. Yang wrote:
> Hi MarLinn,
>
> The mangling name is "z-encoded".  It is documented here:
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames
>
> Edward
>
> Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
>> Hi.
>>
>> 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
>> "Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure".
>> 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,
>> MarLinn
>>



More information about the ghc-devs mailing list