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

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 mailto:monkleyon@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@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs