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/General/Internal/FFI/Builder.hs#L66 example and https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/General/Internal/FFI/Constant.hs#L89 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 <alexander.r.f...@gmail.com>wrote: > 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 > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
