On Mac OSX 10.9, the default c compiler bundled with Xcode is clang. I installed gcc-4.9 with homebrew. Now I have two different gccs, one is clang, the other is gcc. The default is clang.
I want to use gcc when compiling Haskell files with ghc, and I want also gcc when I launch ghci. How to do this change?
Reproducing my directions I've been sharing with haskellers for the past few months via https://gist.github.com/cartazio/7131371
Type ghc --print-libdir
The output will be a path like /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3
Go to that directory and edit the settings file.
There'll be a line indicating the path to the C compiler. It'll probably say /bin/gcc
Change that line to /usr/local/bin/gcc-4.8 (or whichever gcc version you brew installed, such as /usr/local/bin/gcc-4.2)
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.
I believe my question is similar to this post: Linux: cannot find lgfortran though gfortran is installed.
However, since the suggested answer does not fix my problem, there seems no other choice other than asking it again, for a desperate Linux new comer like me.
Here is the problem. I installed GNU fortran compiler 4.8.4 and can find it in terminal
$ which gfortran-4.8
/usr/bin/gfortran-4.8
and
$ locate gfortran
/usr/bin/gfortran-4.7
/usr/bin/gfortran-4.8
/usr/bin/x86_64-linux-gnu-gfortran-4.7
/usr/bin/x86_64-linux-gnu-gfortran-4.8
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortranbegin.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortranbegin.a
/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
/usr/share/doc/gfortran-4.7
/usr/share/doc/gfortran-4.8
/usr/share/doc/libgfortran-4.7-dev
/usr/share/doc/libgfortran-4.8-dev
/usr/share/doc/libgfortran3
/usr/share/man/man1/gfortran-4.7.1.gz
/usr/share/man/man1/gfortran-4.8.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.7.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.8.1.gz
/var/cache/apt/archives/gfortran-4.7_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/gfortran-4.8_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran-4.7-dev_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/libgfortran-4.8-dev_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran3_4.8.4-2ubuntu1~14.04_amd64.deb
/var/lib/dpkg/info/gfortran-4.7.list
/var/lib/dpkg/info/gfortran-4.7.md5sums
/var/lib/dpkg/info/gfortran-4.8.list
/var/lib/dpkg/info/gfortran-4.8.md5sums
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.list
/var/lib/dpkg/info/libgfortran3:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.postinst
/var/lib/dpkg/info/libgfortran3:amd64.postrm
/var/lib/dpkg/info/libgfortran3:amd64.shlibs
/var/lib/dpkg/info/libgfortran3:amd64.symbols
So gfortran seems installed, although I don't understand why 4.7 version is still there after my removing it.
In setting Global Compiler Settings of Code:Blocks, when I choose GNU Fortran Compiler, and its Toolchain Executables, I tried the installation directory as
/usr
/usr/bin
and
/usr/lib/gcc/x86_64-linux-gnu/4.8/
as suggested in the previous post, Code:Blocks tell me
could not auto-detect installation path of "GNU Fortran Compiler".....
More details of compiler configuration is here in the image (Thanks to Mike's suggestion).
And here's the full list of compilers on my computer:
List of Compliers
Your posting shows that you have both gfortran-4.7 and gfortran-4.8
installed under /usr/bin.
Having multiple GCC Fortran compilers (or multiple C or C++ compilers) is
perfectly valid and commonplace. Code::Blocks will allow you configure
as many Fortran compilers as you have got, provided you give them different
names. It's also fine if you just want to configure one of them as the
"GNU Fortran Compiler" and ignore the others.
But in any case, Code::Blocks must be able to unambiguously identify the
installed compiler that you are calling "GNU Fortran Compiler". You
have specified the Compiler's installation directory as /usr/bin
and have left the Program files compiler name as gfortran.
There is no such compiler as /usr/bin/gfortran in your system,
and there is no program called gfortran anywhere in your PATH. You
have /usr/bin/gfortran-4.7 and /usr/bin/gfortran-4.8. As you have
installed both of them, Code::Blocks assumes you want both of them. It
can't tell which one of them you want to configure as "GNU Fortran Compiler".
So:-
Set Compiler's installation directory = /usr/bin
In Program files, change all occurrences of gfortran to gfortran-4.8,
if you want "GNU Fortran Compiler" to mean gfortran-4.8.
OK out.
Default compiler name in 20.3 version was mingw32-gfortran. However, the executable name coming with installation is x86_64-w64-mingw32-gfortran. If this is written in compiler settings. It works.enter image description here
The install file codeblocks-20.03mingw-setup installs the file gfortran.exe into the C:\Program Files\CodeBlocks\MinGW\bin directory. However the Settings>Compiler>toolchainexecutables autodetect function looks for mingw32-gfortran.exe.
To fix this, in toolchainexecutables, change the filename mingw32-gfortran.exe to gfortran.exe in 3 places, then autodetect will find it.
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 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.
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.