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

[MarLinn]

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!

Cheers,
MarLinn

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](https://github.com/DanielG/rts-loader/blob/master/System/Loader/RTS.hs#L275).
>
> 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 gmail.com
>>> <mailto:monkleyon at gmail.com>> wrote:
>>>
>>>      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.
>>>
>>>
>>> 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 gmail.com <mailto:allbery.b at gmail.com> ballbery at sinenomine.net
>>> <mailto:ballbery at sinenomine.net>
>>> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs