-
Notifications
You must be signed in to change notification settings - Fork 97
Dynamically load libm on Linux for each new session #723
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this is the best solution, but in any case it buys some time until we can figure it out. Thanks for the continued digging on this @bubba !
A fair point to make is that currently this is only relevant for HLS, and therefore maybe it belongs in the HLS Main module |
There was a way I saw originally to load in libm without the |
Can you rebase or otherwise retrigger CI somehow? I need a green light to merge! |
@pepeiborra /azp run should work for anyone with write access to the repo I believe. |
/azp run |
No pipelines are associated with this pull request. |
This fixes the issue on Linux where the binary was statically linked and Template Haskell (or the eval plugin on haskell-language-server) tried to evaluate some code. It would previously fail to load ghc-prim because it couldn't lookup symbols from libm which are usually dynamically linked in.
06e6d1c
to
c843ebd
Compare
hm /azp run probably got lost in the repo transfer. Try it out on new PRs. |
This fixes the issue on Linux where the binary was statically linked and Template Haskell (or the eval plugin on haskell-language-server) tried to evaluate some code. It would previously fail to load ghc-prim because it couldn't lookup symbols from libm which are usually dynamically linked in.
This fixes the issue on Linux where the binary was statically linked and Template Haskell (or the eval plugin on haskell-language-server) tried to evaluate some code. It would previously fail to load ghc-prim because it couldn't lookup symbols from libm which are usually dynamically linked in.
This fixes the issue on Linux where the binary was statically linked and Template Haskell (or the eval plugin on haskell-language-server) tried to evaluate some code. It would previously fail to load ghc-prim because it couldn't lookup symbols from libm which are usually dynamically linked in.
This fixes the issue on Linux where the binary was statically linked and Template Haskell (or the eval plugin on haskell-language-server) tried to evaluate some code. It would previously fail to load ghc-prim because it couldn't lookup symbols from libm which are usually dynamically linked in.
See haskell/haskell-language-server#221
Unfortunately we can't just statically link in
libm
and have the binarydlsym
on itself apparently: https://stackoverflow.com/questions/14289488/use-dlsym-on-a-static-binarySo now the statically linked binary actually dynamically links in
libm
on a "best-effort" case: From what I can tell iflibm
is not available this will just print an error to stderr and carry on as usual (albeit it will trip up on Template Haskell), and if the binary dynamically linked then this will have no effect.cc @pepeiborra