Can I get the internal name of a package at runtime?
monkleyon at gmail.com
Sun Oct 15 14:37:17 UTC 2017
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,
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
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:
> 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.
> 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
>> 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!
>> 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
>>> 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
>>> 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
More information about the ghc-devs