-
Notifications
You must be signed in to change notification settings - Fork 10
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
make LibClang work in GHCI on both osx and linux #33
Comments
I can confirm that b2710b9 is building on 32-bit linux (Ubuntu 12.04.2) |
It's building for me also on 64 bit debian, it just doesn't work in ghci |
Sorry, I should have said "works in ghci" above instead of "works", i'll edit it |
I'm puzzled, as the docs seem to suggest this should work. I'll install Ubuntu in a VM tonight and debug this. |
Sorry this is taking so long. I can't believe how hard it is to get the Haskell Platform to work on Ubuntu 13.04. Totally broken. |
Sigh. So indeed this doesn't work. The root problem is this ghc bug: http://hackage.haskell.org/trac/ghc/ticket/3333 It looks like the developers have decided not to fix this since they're planning to switch to using the system linker soon instead of their own custom linker. This is probably for the best, but it means that it will be a while until statically linking C++ objects works on all platforms. (Looks like at least until ghc 7.8.) |
Actually I see now that ghci doesn't work on OS X either; my previous testing method was just flawed. @ghorn, what you're saying is that if LibClang links to LLVM/libclang dynamically, then ghci worked for you in the past? I can see where that might work, since the problem is that ghci's linker won't resolve weak symbols and __dso_handle, which are needed for C++. Probably by linking dynamically against only the interface exposed by libclang itself, which is a C interface, the issue is avoided. If we go dynamic, then linking is considerably more complex on OS X and I need to wrestle with it more. There's some useful information here: https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac I have spent hours on this approach previously before switching to the current static library approach, so in my opinion we should not delay the release over getting ghci working, especially since the work involved in fixing this will be moot once GHC 7.8 lands. |
What would probably simplify this quite a bit on OS X is if libHSLibClang was built dynamically. Unfortunately, doing that requires that all the dependencies be rebuilt dynamically too, which is a bad user experience, and I am not sure that dynamic Haskell libraries are entirely stable. |
Actually, one thing that might make things easier on OS X is just to set the install name of libclang.dylib to the absolute path where we end up installing it. That may break some things (you'll have to do |
Before the llvm submodule feature, I was building LibClang as normal (statically), and just using the --configure-option=--enable-llvm-shared=libLLVM.so or something like that, and LibClang was working in GHCI. I probably also had to point LD_LIBRARY_PATH at that lib too, I don't remember. I never tested this on OSX, only linux, but I would expect it to work the same on OSX. Is the problem that when we build LibClang, we have to use rpath to point it at the libLLVM.so which we also build, but the install location of libLLVM.so is somewhere in ~/.ghc/../../.. and difficult to determine? How does building libHSLibClang dynamically help things? I would hope that the user would not have to build all of their dependencies a different way than preferred in order to use LibClang. |
AFAICT, the problem is that only dynamic libraries can specify an rpath relative to themselves. Because libHSLibClang is static, any rpaths end up being relative to whatever links to it. That is, if foo links to libHSLibClang.a, rpaths are resolved relative to foo. This is even weirder on OS X; linking does not work the same way as Linux there, because the paths are embedded in the library and not the thing linking to the library. I've never had to deal with this at a low level before so I might've gotten some details wrong, but that's my understanding right now. |
Oh man, this doesn't sound good. If you can't find a hack to get this working, I'm ok with accepting broken ghci until ghc 7.8 magically fixes everything. |
I have an idea for a hack that might work, but I don't have time to try it out for a couple of days. I'd really this to work because if ghci doesn't work, Template Haskell also doesn't work, and that means I can't conveniently use things like Data.Lens in programs that use LibClang. |
Unless its a quick and easy hack, I'd hold off. Ghc 7.8 would most certainly take care of this. If you'd like, you can build and test against (HEAD)[https://github.com/ghc/ghc] to verify for now, perhaps even work on it. I'll try that this weekend if I get a chance. |
Update on my end: I finally got time to work on this, and I can confirm that LibClang in ghci does work with ghc-HEAD. The work I did to make it release(hackage) friendly is in the llvm3.4_ghc7.8 branch. I've tested the build out in OS X 10.5.8 and Ubuntu 12.04 and can confirm that it builds, installs and is usable. Some changes I did there vs the llvm3.4 branch:
Issues still pending:LibClang can now run on ghci (ghc-7.7+ only), but needs to be explicitly told where the libclang and LLVM-3.4svn libs are located, as well as force their load. so |
update: the rpath issue and the clang dependency issues are both resolved in linux in the llvm3.4_ghc7.8 (perhaps on OS X as well, will test the changes on a mac when I get a chance). |
That sounds very good! Thanks for working on this. I can't wait to try it out! My only concern is related to the |
That's true, originally I used |
Ah, that's unfortunate that we can't trivially detect this information from the Haskell side. (Maybe I'd imagine that most people installing this will have either 2 or 4 hyperthreaded cores. In the worst case, |
I haven't use LibClang for a few months, If you give me a hello world script I'll build LibClang and ensure the script runs tomorrow |
@ghorn That would be a great help! You don't even need a script to test. It's enough to install LibClang, run GHCi and type this at the GHCi prompt:
It should return the value "clang version 3.4". On OS X this will only work with GHC 7.8.x, but I'm not sure about linux. |
A few days ago I built and tested the head against ghc 7.8.1 in Ubuntu 13.04
|
the hello world works |
@chetant I think all of the tests are outdated. At least the ones in the test folder. I couldn't get any to typecheck, and the modules are outdated |
Yeah, I broke them in the past few days, unfortunately. =) I moved some of the types around between modules. I'm going to move some of the types around again today, and when I get that done I'll get the tests updated, too. |
@ghorn Thanks so much for checking that LibClang works for you in GHCi, by the way! It's been tricky to keep OS X and linux working simultaneously. Having more people testing really helps. |
No problem! Ping me if you need more |
As discussed in b98dbf9, apparently LibClang only works in ghci on osx if it is built statically. I don't understand that, but if it works, it works. On linux, it only works in ghci if it's build shared. I used to use --configure-option=--enable-llvm-shared=LLVMSHAREDLIB but now that llvm is a submodule i don't think that works anymore.
The text was updated successfully, but these errors were encountered: