Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading temp shared object failed when using template haskell and foreign functions #8466

Closed
k355l3r-5yndr0m3 opened this issue Sep 12, 2022 · 3 comments
Labels
Cabal: stanza/foreign-library re: dynamic-linking Concerning dynamic linking (e.g. flags "shared", "*-dynamic")

Comments

@k355l3r-5yndr0m3
Copy link

I'm working on a pet project which required a library written in c (tensorflow to be specific). I've written several c files which wrap the functions it provides in a more ffi friendly formats. My project compiles fine without template haskell.
If I try to splice, then when I compile, ghc comes up with this.

GHC.Linker.Loader.dynLoadObjs: Loading temp shared object failed
During interactive linking, GHCi couldn't find the following symbol:
/tmp/ghc550097_0/libghc_1.so: undefined symbol: TF_DeleteGraph
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
After digging around for a while, I found this (#7082), which almost fix my problem except now ghc complain that it cannot find the c wrapper functions that I wrote.
The underlying problem seems to be that cabal doesn't pass the linker flags to ghc (both for the external library and object files that cabal compiles)

  • Archlinux 5.19.5
  • cabal 3.8.1.0, ghc 9.2.2, installed via ghcup
@Mikolaj
Copy link
Member

Mikolaj commented Sep 13, 2022

I know some of these words and some also appear in #8461. Is this related by chance?

I wonder if that's perhaps an upstream GHC issue. Are you able to compile your program fine by invoking ghc directly with the proper flags (using the intermediate artifacts produced by cabal and stored on the filesystem)?

@Mikolaj Mikolaj added Cabal: stanza/foreign-library re: dynamic-linking Concerning dynamic linking (e.g. flags "shared", "*-dynamic") labels Sep 13, 2022
@Mikolaj
Copy link
Member

Mikolaj commented Sep 13, 2022

BTW, I know things around foreign libraries have changed in GHC 9.4 and in 3.8.1.0. If that sounds relevant, you want to try cabal 3.6.3 and GHC < 9.4 and cabal 3.8.1 and GHC 9.4.2 and verify it behaves the same.

@alt-romes
Copy link
Collaborator

It is a little bit hard to help on this issue without any kind of reproducer.
I'm going to close it in the meantime, but if you do have a reproducer (even a large one!) for this bug with a more recent toolchain do re-open. I believe the issue is likely fixed by the improvements done in the meantime to linking in Cabal and GHC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cabal: stanza/foreign-library re: dynamic-linking Concerning dynamic linking (e.g. flags "shared", "*-dynamic")
Projects
None yet
Development

No branches or pull requests

3 participants