Hey Alex,
very very cool!
a few thoughts: ghc stage1 has no GHCI, and thus can't build / use a lib
that has template haskell.
LLVM-General uses template haskell pretty heavily to generate the FFI code!
see
https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/G...
example and
https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/G...
for another
so your choices are: figure out how to support TH in stage 1 ghc, OR use
llvm-general-pure, and cope with just having llvm pretty printing and
parsing. Alternatively, you could treat the "llvm-general" way as being an
alternative to the -fasm and -fllvm backends, and have it only be built /
supported in the stage2 backend.
point being: start with getting -flllvm working just using llvm-general-pure
then once you've got that working, having an llvm alternative that can ghc
can enable in stage2 (when ghci/th is a thing) can be made to work.
either way, very cool! it gives a path towards bundling llvm with ghc, or
at least is a decent experiment towards that.
one thing you may want to consider is how to remove the TH deps from llvm
general. This would make it possible use it in stage1 GHC, which would make
it much more likely to be actually merged into GHC proper.
again, props for getting this experimentation started!
-Carter
On Tue, Nov 12, 2013 at 2:53 PM, Alex Ford
Hi,
I've made some changes to the LLVM backend of GHC to make it use llvm-general to output bitcode rather than pretty printing human readable LLVM assembly. However, I've been having trouble linking the required libraries (llvm-general and its transitive dependencies). The steps I've taken so far are to put the required libraries in the build tree under libraries, and added them to the packages file, to PACKAGES_STAGE0 and PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ ghc.cabal.in.
The build fails in phase 1 when trying to link utf8-string (a dependency of llvm-general) during the build of llvm-general, with: Loading package utf8-string-0.3.7 ... <command line>: can't load .so/.DLL for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open shared object file: No such file or directory)
The problem seems to be that with pre-existing library dependencies, the system-wide libraries at /usr/lib/ghc-7.6.3/<libname>/ are pulled in, whereas with the new dependencies, versions within the build tree (e.g. at libraries/utf8-string/dist-install/build/) are tried instead, despite these new libraries being installed globally within the same parent directory and being listed by ghc-pkg (no errors upon ghc-pkg check either).
For example, in compiler/stage1/package-data.mk, compiler_stage1_DEP_LIB_DIRS_SEARCHPATH specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links successfully, but for utf8-string specifies <ghc-base-dir>/libraries/utf8-string/dist-boot/build.
I've read through the documentation on libraries for GHC but can't figure out how to make this work. Could anyone suggest how I could go about fixing this?
As a slightly related question, llvm-general depends on template-haskell. Will this cause problems when building GHC normally, since the stage 1 compiler does not support TH? If so is there any way to compile stage 2 directly using the stage 0 compiler?
Many thanks, Alex
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users