ghc 7.4.1 not producing stub.o files - haskell

I'm running the default installation of Haskell platform on Ubuntu and when I run this example http://www.haskell.org/haskellwiki/Calling_Haskell_from_C "ghc -c -O Safe.hs" is not producing the Safe_stub.o file. I have checked this on a separate installation of Ubuntu on a friends box and on both 32 bit and 64 bit Ubuntu installs.
Can somebody confirm if this is specific to ghc-7.4.1 or Ubuntu installs only?
Thanks!

It's a ghc-7.4 (ghc >= 7.2 actually) thing. That doesn't need and produce *_stub.o (or *_stub.c) files anymore. However, the command line for the final compilation has to change
$ ghc -no-hs-main -optc-O test.c Safe.o -o test
You have to tell GHC that the main is not a haskell call.

Related

Why does GHC run version 7.10.3 instead of 8.6.2?

I am new to Haskell (as in, have yet to write a single line of Haskell code). I recently downloaded GHC version 8.6.2 on Ubuntu 16.04 via the ppa:hvr/ghc. However, when I run
$ ghc --version
I get
The Glorious Glasgow Haskell Compilation System, version 7.10.3
I can run version 8.6.2 using the command
$ /opt/ghc/bin/ghc-8.6.2 --version
so I assume this is normal behaviour. However, I don't understand why it automatically runs version 7.10.3. Additionally, is there a way I can change it so that the ghc command will automatically run the latest version installed?
I did try searching for answers previously, but was unable to find any. Any explanations / help would be appreciated.
You seem to have a misunderstanding about ghc, system administration, or both.
GHC ships as individual versions of the compiler - just as gcc or any other compiler I can think of. If you run the ghc 8.6.2 binary then it will report version 8.6.2. If you run some unknown ghc and ask it for the version, as you did with just $ ghc --version, then you'll see the results from the first ghc binary in the path. You can even find out which binary using which ghc and ls -l $(which ghc).
So you seem to have multiple GHC binaries installed. Again, this is something to do with your administration of this system. I suggest you:
Go through and remove any previously installed GHC binaries from apt etc
Set a path to include the HVR PPA ghc you just installed. For example, edit $HOME/.bashrc if you use bash and add PATH=/opt/ghc/bin:$PATH to the end of the file.

Remove all previous version MPI and reinstall correctly it

First of all: I'm on linux mint 17.3 x64
What I've done so far:
Guide to install Open MPI 1.8
Guide to install MPI
Attemp to remove MPI executing: sudo apt-get install libcr-dev mpich2 mpich2-doc (Actually the should be not installed)
What I can see from terminal:
output of: echo $PATH
/path/to/mpj//bin:/home/timmy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/timmy/.openmpi/bin
(I immagine that I've to remove /path/to/mpj/ (not exists) and /home/timmy/.openmpi/bin (I want to remove previous version of ompi))
output of: echo $LD_LIBRARY_PATH
(nothing)
Really, doesn't appear anything!
output of mpirun
--------------------------------------------------------------------------
mpirun could not find anything to do.
It is possible that you forgot to specify how many processes to run
via the "-np" argument.
--------------------------------------------------------------------------
Why I want to remove Open MPI and reinstall it
I've a project to do using both MPI and OpenMP and with the actual installation of MPI I cannot compile using the following command: mpicc -openmp "test_omp.c" -o "test_omp". It gives me the following error: Not defined function omp_get_thread_num(); and moreover, it ignore my #pragma commands.
Your problem is that you are giving the compiler the wrong option to enable the OpenMP support. -openmp is only understood by the (commercial) Intel compiler, which is probably the tool-set installed on the site you've referred to in your other question. Most Linux distributions come with GCC and one is to assume that mpicc will use GCC (check with mpicc -showme).
The option to enable OpenMP support in GCC is -fopenmp (notice the f).

Installing Haskell Platform overrides gcc location in system PATH

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.

How can I specify which LLVM binaries GHC should use?

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.

Haskell program built on Ubuntu 11.10 doesn't run on Ubuntu 10.04

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.

Resources