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

Linking error while using cabal repl #122

Open
deliciouslytyped opened this issue Dec 28, 2020 · 2 comments
Open

Linking error while using cabal repl #122

deliciouslytyped opened this issue Dec 28, 2020 · 2 comments
Labels

Comments

@deliciouslytyped
Copy link

As discussed on IRC here is as far as I could currently minimize the repro.
To repro, nix-shell and then call cabal repl.
I haven't been able to update things yet so it's running with old code and an old pinned version of nixpkgs.

The clang-pure directory contains the slightly modified clang-pure.
The significant changes wrt. the issue should (?) be limited to the cabal files.
repro.zip

@deliciouslytyped
Copy link
Author

deliciouslytyped commented Dec 29, 2020

I don't have energy left to do a cleaner writeup today; the issue seems to be that an extraneous typeinfo for clang::ast_matchers::MatchFinder::MatchCallback symbol ends up in the clang-pure shared object, which GHCi fails to resolve when it tries to load it, because the symbol doesn't exist. The symbol doesn't exist the original clang shared objects either, because they are compiled with -fno-ffi. (TODO: I should confirm this last point.)

The hypothetical solution would be to do whatever is necessary so that the symbol requirement isn't created.

I couldn't figure out a hacky way to test this with the raw binary, because I couldn't find any linker/tools that could remove the symbol, or at least I couldn't figure out how to do it. (TODO: there was a mailing list item that I believe said it's possible with the ld linker script VERSION feature?)

@deliciouslytyped
Copy link
Author

The issue superficially appears to have been fixed by updating to GHC 8.10.

@roberth roberth added the bug label Apr 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants