I am trying to install the paradox theorem prover sourced from here.
When I run the makefile this is the command that runs:
ghc -optl -static -lstdc++ -I../instantiate -I../minisat/current-base ../minisat/current-base/Solver.or ../minisat/current-base/Prop.or ../instantiate/MiniSatWrapper.or ../instantiate/MiniSatInstantiateClause.or -fglasgow-exts -O2 -static -threaded -main-is Paradox.Main.main --make Paradox.Main -o paradox
And it results in several errors like so:
Flags.hs:52:8:
Could not find module ‘Char’
Use -v to see a list of the files searched for.
for a variety of modules including but not limited to Char, CPUTime, IO.
The final error message is
Makefile:38: recipe for target 'paradox.exe' failed
make: *** [paradox.exe] Error 1
I don't know Haskell, nor am I very experienced with GNU make, but I am trying to install this package for a project and it is obscure enough to not be packaged for my OS (I'm running Arch Linux). As far as I know it is not packaged for any OS, so it is necessary to install from source.
As far as I can tell the problem starts with the following error message:
on the commandline: Warning:
-fglasgow-exts is deprecated: Use individual extensions instead
I am using the version of the GHC provided in the Arch Linux package repository: package link
Looks like paradox was written for a rather old version of GHC. You can fix all these "Could not find module" errors by using GHC version 7.8 or older and setting
GHC = ghc -hide-package base -package haskell98
in the Makefile, though you will likely encounter more errors after that.
The warning about -fglasgow-exts is mostly harmless, you can ignore it.
Related
I'm pretty new to Haskell, and I think I have a fundamental misunderstanding somewhere. When I'm in GHCi (using the ghci command), I can type import System.Random, and it works. I can then generate random numbers.
Next, I make a file called test.hs that contains nothing but one line: import System.Random. I then call the command ghc test.hs and get the following error message:
test.hs:1:1: error:
Could not find module ‘System.Random’
There are files missing in the ‘random-1.1’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
1 | import System.Random
| ^^^^^^^^^^^^^^^^^^^^
However, if I go back to GHCi, I can type :load test.hs. This works, and allows me to generate random numbers.
When I run ghc-pkg check, I get only warnings about missing haddock interface files: https://pastebin.com/6a9f0nYZ. From what I understand, this isn't related to the current issue.
Also, when I run ghc-pkg list, random-1.1 is in the list, so random should be installed.
A couple of questions:
Why would GHC and GHCi have access to different imports? Why is the system set up that way? Maybe I just don't understand the relationship between GHC and GHCi.
According to the error message, there are "files missing." How can I figure out which files?
How can I make it so that I can compile Haskell files that use System.Random?
Edit: Both GHC and GHCi are the same version.
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.4
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 8.6.4
Edit: Both ghc and ghci are in /usr/bin/
$ which ghc
/usr/bin/ghc
$ which ghci
/usr/bin/ghci
Update: It looks like this is an Arch Linux peculiarity, not a corrupt package. I've updated my answer accordingly.
GHCi loads "dynamic" versions of modules. By default, GHC links with "static" versions of modules. In particular, when you run:
> import System.Random
under GHCi, it tries to access the file Random.dyn_hi to get interface information for the module. In contrast, when you compile a file with that import statement in it, GHC tries to access the file Random.hi.
You can verify this is the issue by running ghc-pkg field random import-dirs and peeking in the resulting directory. There should be a System subdirectory that usually has two files in it: System.hi and System.dyn_hi. If the former is missing, that's your problem.
Now, it looks like you're probably using Arch Linux. As documented on the Arch Haskell wiki page in the section "Problems with linking", the Arch Haskell community packages (including haskell-random) intentionally omit the static versions of interface files and libraries.
There are several of workarounds given there:
You can use dynamic linking when compiling with GHC. When using GHC directly, this just means passing the -dynamic flag. For Cabal-based projects, instructions are given on that page for modifying your ~/.cabal/config to use dynamic linking for all projects.
You can install the ghc-static and ghc-pristine packages and set up your path and/or Cabal to use the compiler in /usr/share/ghc-pristine/bin/ghc which will maintain its own separate package database that won't interfere with globally installed Haskell community packages, like haskell-random.
You can install ghc-static to get static versions of the base libraries and then run cabal install --force-reinstalls somepackage for all the non-base packages you need. Note that the Wiki notes that this can be tedious and complicated, since you have to manually determine all the package dependencies.
Now, it looks like you already had ghc-static installed, or when invoking GHC you would have also gotten an error about missing files in the base package. You ran cabal install --force-reinstalls random, though as #dfeuer notes, it might have been safer to run:
$ cabal install --force-reinstalls random-1.1
to ensure that the same version was reinstalled.
Anyway, this installed an additional copy of random in your user-specific package directory. If you run:
$ ghc-pkg list
you'll see that random-1.1 is listed both under the global database and user database:
/usr/lib/ghc-8.6.4/package.conf.d
...
random-1.1
...
/home/xxxx/.ghc/x86_64-linux-8.6.4/package.conf.d
random-1.1
and if you run:
$ ghc-pkg describe random
you'll see that it lists the two separate installed versions which is why you now get duplicate fields with ghc-pkg field random import-dirs.
There shouldn't be anything wrong with this. Your user database will take precedence over the global database, so your newly installed version of random will be used when you run GHCi or GHC.
Note that, if you change your mind and want to back out this reinstallation (and maybe try one of the other solutions suggested on the Wiki), you should be able to run:
$ ghc-pkg unregister --user random
Technically, this won't actually remove the package (as the compiled version will still be there under ~/.cabal/lib), but it should otherwise put things back the way they were.
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.
I am working on a Haskell program which is linked to some old C++ code. I created a C interface and got it working with ghc only. Now I tried to convert the used Makefile into a Cabal project and now cabal on the last step selects the wrong linker.
Because of some dependencies I have to use a quite old ghc and gcc. So what I am doing is calling cabal (1.24.0.0.) like this:
cabal install --with-ghc=ghc-7.6.3 --with-gcc=/opt/gcc-3.3.6/bin/gcc --with-ld=/opt/gcc-3.3.6/bin/gcc
For the compile- and intermediate configure linking all is ok, with -v3 I get the following lines:
Using gcc version 3.3.6 given by user at: /opt/gcc-3.3.6/bin/gcc
Using ghc version 7.6.3 given by user at: /home/oswald/ghcs/bin/ghc-7.6.3
...
Using ld given by user at: /opt/gcc-3.3.6/bin/gcc
All works fine until the final linking step:
Linking dist/dist-sandbox-c45ed4c7/build/MISCconfig/MISCconfig ...
*** C Compiler:
'/opt/gcc-3.3.6/bin/gcc' '-c' '/tmp/ghc28340_0/ghc28340_0.c' '-o' ...
*** C Compiler:
'/opt/gcc-3.3.6/bin/gcc' '-c' '/tmp/ghc28340_0/ghc28340_0.s' '-o' ...
*** Linker:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-W
So the last line specifies /usr/bin/gcc as the linker, which is the system one and therefore I get link errors where it should be /opt/gcc-3.3.6/bin/gcc (have to use a pre-3.4.0 gcc because of link compatibility for one of the used C++ libraries and gcc 3.3.6 is the latest with the old ABI).
So what I am doing wrong? Cabal says it selects the linker from the old gcc but then actually uses the newer one from the system?
When I just use ghc with the -pgmc /opt/gcc-3.3.6/bin/gcc switch in a makefile all works but I would prefer to get a cabal sandbox working...
This apparently had nothing to do with Cabal, which does not instruct GHC to use the C compiler specified by the Cabal option --with-gcc.
Use -pgml to select the linker as documented on the GHC man page.
(One point that may cause confusion for others and is worth mentioning. GHC always uses a C compiler to do the final link step. That means -pgml must refer to something like gcc, not something like ld. Consequently flags intended to be consumed by ld such as -rpath must be prefixed by -Wl, before being fed to -optl.)
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
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.