Oh, wait, that won;t work because you're trying to find the name of something to load at runtime. But you can still z-encode the known parts of the name and look for files starting and ending with those components; the ABI hash won't matter because a dynamically loaded plugin can't use the inlinings from the .hi file anyway. If you get multiple matches, you could warn about it but because you can't use the .hi inlinings in that context it won't matter which one you load.
On Sat, Oct 14, 2017 at 4:19 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Sat, Oct 14, 2017 at 3:59 PM, MarLinn <monkle...@gmail.com> 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. >> > > I can think of a hacky way: make sure the symbol table is still present in > the executable and that you can find said executable, z-encode the part of > the package+version you know and a symbol you know, and look for symbols > that start with one and end with the other; the hash will be in between. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@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
