I have successfully built PortFusion with the brand new 64-bit GHC 7.6.1 Release Candidate 1 for Windows.
Using freshly downloaded native 64-bit mingw binaries from http://www.drangon.org/mingw, the network package was as easy to install (after a bunch of non-relevant small fixes) as a simple
CC=mingw64/bin/gcc cabal install
There is also an LLVM toolchain package on the same website.
Now I wonder how I could tell GHC to use specific LLVM binaries during compilation.
Would it be something as simple and similar to above as:
#v??v
LLVM=????????? ghc -W -O2 -fllvm -optlo-O3 --make src/Main.hs
LLVM=????????? cabal install PortFusion -f llvm #¹
#^??^
¹ relevant line in PortFusion.cabal defining the llvm flag
or completely different?
For the record, the answer to the question in the title is
ghc -pgmlo opt_cmd -pgmlc llc_cmd -fllvm ...
opt_cmd and llc_cmd can be either command names (that will be looked up in PATH) or full pathnames.
You may be able to get GHC to use certain binaries by altering where they are defined in the PATH environment variable. Earlier takes precedence. Presumably, System PATH is also higher precedence than User PATH.
Related
Recently I was trying to install llvm-general-3.5.1.0 package.. for about a week. Basically I am getting this error: link. My situation is identical. Windows 10, ghc 7.10.2, cabal 1.22.4.0. I installed llvm 3.5.2 from sources with cmake and everything went fine. In llvm/lib directory I have *.lib files (eg. LLVMAnalysis.lib).
But somehow cabal can't see those libraries and gives this frustrating error:
Configuring llvm-general-3.5.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: LLVMLTO, LLVMObjCARCOpts, LLVMLinker, LLVMipo,
LLVMVectorize, LLVMBitWriter, LLVMCppBackendCodeGen, LLVMCppBackendInfo,
LLVMTableGen, LLVMDebugInfo, LLVMOption, LLVMX86Disassembler,
LLVMX86AsmParser, LLVMX86CodeGen, LLVMSelectionDAG, LLVMAsmPrinter,
LLVMX86Desc, LLVMX86Info, LLVMX86AsmPrinter, LLVMX86Utils, LLVMJIT,
LLVMIRReader, LLVMAsmParser, LLVMLineEditor, LLVMMCAnalysis,
LLVMMCDisassembler, LLVMInstrumentation, LLVMInterpreter, LLVMCodeGen,
LLVMScalarOpts, LLVMInstCombine, LLVMTransformUtils, LLVMipa, LLVMAnalysis,
LLVMProfileData, LLVMMCJIT, LLVMTarget, LLVMRuntimeDyld, LLVMObject,
LLVMMCParser, LLVMBitReader, LLVMExecutionEngine, LLVMMC, LLVMCore,
LLVMSupport
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
I really want to use this package on my Windows, but nothing seems to work (I tried everything like --extra-lib-dirs and compiled also with MinGW and VS - the same problem).
I can't accept the fact that it won't install. I mean, there must be some way to fix Setup.hs from this cabal package or something. Does anyone have an idea what can be wrong with cabal in this case and how can I try to workaround this? I don't know how exactly cabal works, maybe someone with this knowledge will have an idea? Or maybe there is a way to do this without cabal?
Ok, i've managed to build it and, i think, found the root of the issue.
First, steps to build:
Get the MinGW. My installation of MinGW has gcc 4.8.
Get 32-bit MinGHC.
Compile LLVM 3.5 with MinGW's gcc and install it somewhere.
Copy contents of MinGW installation directory into MinGHC Install
Dir\ghc-7.10.2\mingw, replacing conflict files.
In the command line set your PATH so it has haskell toolset from
MinGHC (i recommend using switch .bat scripts) and llvm-config.exe.
Get the llvm-general package source either using cabal fetch or
downloading via browser from hackage.
Replace cc-options: -std=c++11 line of llvm-general.cabal with
cc-options: -std=gnu++11.
Finally, cabal configure and cabal build should work.
I have been changing my build environment many times, so if this doesn't work for you let me know, i probably forgot something.
Now let's go into details.
What we thought is a bug of cabal is not, actually. The problem is that both stack and MinGHC (and Haskell Platform, i guess) use quite old gcc - 4.6. This gcc has even two defects:
It doesn't support -std=c++11 and LLVM 3.5 can't be built using it.
As a consequence, this gcc can't be used by ghc when compiling
llvm-general, because it can't parse LLVM headers properly.
Even if it could, its linker can't link against LLVM libs compiled by
MinGW using gcc 4.8. This is why cabal was telling you it
couldn't find LLVM libs. I've hacked Setup.hs so that it wouldn't
look for these libs, but pass -lLLVMSomething to linker via -pgml
ghc option. This lead to clear error message:
ld.exe: ignoring libLLVMSupport.a ...
ld.exe: can't find -lLLVMSupport
So, the cabal was actually finding these libs, but was dropping them because they couldn't be linked to.
Ideally, the solution would be to update mingw distribution used by stack/MinGHC. But as a workaround you can just replace old gcc with new one.
Finally, -std=gnu++11 is used because current MinGW release is affected by this bug, which prevents compilation of c++ bits of the package. Whew, that was a long way.
again...
I'm messing around with profiling in GHC after recently starting to learn Haskell. I'm trying to use profiling to see how different implementations of functions vary in performance, for example using list comprehension instead of map. I'm trying to compile with the -prof flag but im getting the following output:
david#david-LinuxMint ~/Desktop/Sandbox/Haskell/a $ ghc --make Filt -prof
Filt.hs:1:1:
Could not find module `Prelude'
Perhaps you haven't installed the profiling libraries for package `base'?
Use -v to see a list of the files searched for
The program compiles fine with the -prof flag omitted. Anybody have any ideas where im going wrong? I've tried to find something on SO/internet but my Google-Fu is failing me? Cheers.
This is for Linux, Debian in particular, but I believe the OP is using Mint which I think might be a Debian variant.
You probably got base from the OS packaging system (Debian: APT), so you'll also want to get the profiling version of base from that same system. On Debian the hackage package "foo" is in the Debian package "libghc-foo-dev"[1]. The profiling version of "libghc-blah-dev" is in the Debian package "libghc-blah-prof".
Now, base is a little special. Those packages exist, but are "virtual"; they are listed in relationships, but are actually installed by (one or more) other real packages. In Debian virtual libghc-base-dev is provided by real package ghc and virtual libghc-base-dev is provided by real package ghc-prof.
So, install ghc-prof (or the Mint equivalent) and you'll be good, or at least move on the the next error.
Eventually, you'll end up downloading and building packages directly from hackage. You'll have to change your cabal settings to build the profiling versions of those libraries.
[1] If another Haskell compiler gets (back) into Debian, the "ghc" in "libghc" will change to a string suitable for that compiler.
Is there a place I can configure some default flags for GHC to use? I'd like, i.e., GHC to always assume I want the -fwarn-incomplete-patterns flag. This page gives a list of useful flags and indicates that some of them are on by default, but again, I'd like to change the defaults for my system.
I'm currently working on OS X, but I use Debian, Arch Linux, and Windows 8.1 at home, so a solution for any platform will help.
Apart from aliasing the shell command ghc to ghc -fwarn-incomplete-patterns, I don't think there's a way to do it globally or whether it would be advisable to do globally since it would probably generate an enormous amount of warnings when compiling external libraries with cabal. Probably best to do this one project at a time or just with GHCi:
There's a ghc-options section in any cabal file for a project.
library
...
ghc-options:
-fwarn-tabs
-fwarn-missing-local-sigs
-fwarn-incomplete-patterns
-fwarn-incomplete-uni-patterns
For global GHCi, you can add the following line to your ~/.ghc/ghci.conf
:set -fwarn-incomplete-uni-patterns
Add ghc-options: -fwarn-incomplete-patterns to the program-default-options section of your ~/.cabal/config:
[...]
program-default-options
...
ghc-options: -fwarn-incomplete-patterns
...
This only works with Cabalised projects (i.e. when you use cabal build/install/[...] instead of running ghc --make SomeFile.hs manually) and requires a fairly recent cabal-install (>= 1.18).
Just because this will be useful for people who come here:
On Gentoo, you can set options for all Cabal packages, (which is pretty much all of them) globally, in /etc/portage/make.conf, with the variable CABAL_EXTRA_BUILD_FLAGS. So in your case, that would be
CABAL_EXTRA_BUILD_FLAGS="--ghc-option=-fwarn-incomplete-patterns"
, and here is a more advanced example
CABAL_EXTRA_BUILD_FLAGS="--ghc-option=+RTS --ghc-option=-M1G --ghc-option=-RTS"
to limit memory usage to 1GB (and exit otherwise).
I think there’s a similar solution for Arch and Debian, but since OS X is a consumer OS, I don’t know.
I am running the latest version of MinGW GCC 4.7.2, and it was working fine with -std=c++11 before I installed Haskell using Haskell Platform. Please take a look at this:
For some reason, the GCC went back to 4.5.2, after installing Haskell, I re-installed it, with version 4.7.2, but its still showing 4.5.2.
Haskell adds its own GCC to your system PATH. You can check this is true by running
where gcc
which will show two commands, the Haskell one first, followed by your MinGW GCC.
The solution is to change your PATH to point to the GCC you want (but make sure Haskell still uses its GCC, I doubt it'll agree with GCC 4.7 if it came with GCC 4.5).
The easiest is to have some script ou can run to set up your compilation environment, so you don't have to worry about system PATHs.
If you don't care much about that exact GCC version you had installed, you can get my builds (32-bit and 64-bit), which come with a .cmd file you can doubleclick and it will give you a build environment much like the MSVS commandline shortcut, but for GCC. All it really does is add the compilers to PATH.
I'm trying to provide the users of my program with some Linux binaries in addition to the current Windows ones, so I installed Ubuntu 11.10 (since the haskell-platform package on 11.04 is still the 2010 version). When I try to run the resulting binary on Ubuntu 10.04, however, I get the message that it cannot find libgmp.so.10. Checking /usr/lib reveals that 10.04 comes with libgmp.so.3 whereas 11.10 has libgmp.so.10. It would appear therefore that GHC is linking to libgmp dynamically rather than statically, which I thought was the default.
Is there any way to tell GHC to statically include libgmp in the binary? If not, is there some other solution that does not require the user to install a different version of libgmp?
It turns out that in order to statically link the binary the -static flag is not sufficient. Instead, use:
ghc -static -optl-static -optl-pthread --make yourfile.hs
Using this, my binaries ran correctly on both versions of Ubuntu.
Often, the old libgmp packages are available as well; that is, make your program depend on the libgmp3c2 package instead of a generic libgmp or libgmp10. This can often be achieved by compiling with an earlier version of GHC or the gmp lib (e.g. install libgmp3-dev instead of libgmp10-dev).
You have the ghc option -static to link statically against the libraries.