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.
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 am trying to install Haskell Platform 2014.2.0.0 from source on Red Hat Enterprise Linux 6.5. I have a functional install of Haskell Platform 2012.4.0.0 and GHC 7.4.2 from two years ago, plus a recently-installed Haskell Platform 2013.2.0.0 and GHC 7.6.3 from JustHub.
I've built GHC 7.8.3 from source, but it keeps coming up with seven failures in the test suite. I have no idea if these test failures are innocuous or not. (The test failures are not relevant to my question, but they may become significant later.)
I unpack the source tarball of 2014.2.0.0, read the README. It says that the way to build this iteration of Haskell is with a shell script, which is invoked:
./platform.sh $PATH_TO_GHC_BINDIST_TARBALL
I don't have a GHC binary distribution tarball. So far as I am able to tell, there is no binary distribution tarball of GHC 7.8.3 for any version of Red Hat Enterprise Linux. I have a built GHC 7.8.3. How do I tell platform.sh -- or whatever is underneath it -- that there is no tarball, and it should just use what's in $PATH? Alternately, how do I pack up my existing install of GHC 7.8.3 so that platform.sh will accept it?
The built GHC does not have a 'cabal' command, so the cabal commands in platform.sh are falling back to $PATH, which I can configure to be either of the other installed versions (2013.2/7.6.3 or 2012.4/7.4.2). It doesn't seem to make a difference: neither one recognizes 'cabal --sandbox'. Both result in complaints that I should run 'cd hptool ; cabal install --only-dependencies', which I've done, repeatedly. platform.sh never gets past that point.
If I run the commands in platform.sh by hand, I get to 'cd hptool; cabal build', which errors out: "cabal-1.16.0.2: Run the 'configure' command first.". But there is no 'configure' command available in the hptool directory.
I'm now stuck. How do I build Haskell Platform 2014 on RHEL 6?
You need to use your GHC sources to make your own "bindist." Directions at https://ghc.haskell.org/trac/ghc/wiki/MakingReleases
I managed to get Haskell Platform installed, and functional. I ended up abandoning platform.sh and just hand-installed all the packages in the Haskell Platform tarball -- and their dependencies -- with manual cabal commands. Along with the broken platform.sh, I ran into many problems on the way.
The ones that I remember:
platform.sh will never succeed if you have the stock Haskell Platform 2013 or previous installed. It wants a cabal that recognizes the '--sandbox' option, and cabal 1.18 doesn't know that option. You must have a newer cabal installed than Haskell Platform 2013 provides. (GHC 7.4 or 7.6 appears to be fine, though.)
I had an existing .cabal and .ghc directory, which had incompatible builds and/or versions of various packages. I deleted both directories numerous times while testing things.
cabal install --global behaves rather differently from the default cabal install --user. .cabal contained something useful after I did 'cabal install cabal-install'. It took two or three tries at that to figure out where the new cabal binary went.
ghc and cabal pick up new libraries in .ghc and .cabal, but not new binaries.
Neither GHC nor cabal install default to --enable-shared, except when something wants it. I had to go rebuild everything before that -- all the way back to GHC 7.8.3 itself -- with --enable-shared once that happened.
haddock is ridiculously tightly bound to the version of GHC it was built with. I had to rebuild it to get --enable-documentation to work for anything built with GHC 7.8.3.
The test packages and the text package are so tightly integrated that they have circular dependencies if you try to do 'cabal install text --enable-tests'. Even after installing the most recent version of text and the test packages, cabal still wouldn't run the text test suite, so I gave up and installed text without testing it.
My default environment includes 'LC_ALL=C'. This trips a known bug in cabal -- apparently in all versions -- that breaks some package builds. To work around it, I had to shift it to 'LC_ALL=en_US.utf8'. I have no idea if the packages affected will work if you have LC_ALL, or any of the other locale variables such as LANG or LC_<anything else>, set to C.
cabal install --global is terribly inconsistent about where packages get stored. We split out individual packages into their own subdirectories, and then build a symlink tree in a known place out of all those subdirectories. So ghc is in its own subdirectory of /usr/sup/ghc-7.8.3; Haskell Platform is in another subdirectory, /usr/sup/haskell-platform-2014.2.0.0. I consistently used --prefix=/usr/sup/haskell-platform-2014.2.0.0 on every 'cabal install' command, but even then, some libraries ended up in /usr/sup/ghc-7.8.3.
Both GHC and Haskell Platform have a dictionary of what's built and where it is -- perhaps as a workaround for the install location inconsistency -- in /usr/sup/ghc-7.8.3/lib/ghc-7.8.3/package.conf.d/package.cache. If that package dictionary isn't world-readable, ghc breaks. What it should do is look at the actual file structure to find things. Given that ghc breaks if the dictionary isn't available, the file shouldn't be called 'cache', as a cache miss shouldn't cause catastrophic failure. Perhaps rename it to 'package-mandatory-dictionary'?
Ultimately, it all installed, but I have to wonder about the damage I did from so much banging my head on the wall.
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.
So we have this program which is being compiled in OpenSuse 13.1 with the following configuration:
GCC 4.6-15.1.3
GLIBC 2.14
Libcrypto 1.0
However, it's supposed to run with OpenSuse 10.3 which has the following configuration:
GCC 4.2-24
GLIBC 2.6.1-18
Libcrypto 0.9.8
The only dependency I could find so far was the __isoc99_sscanf which is introduced in GLIBC 2.7. I tried to fix this with writing my own sscanf function and replace it by adding the following line in my source code:
__asm__(".symver __isoc99_sscanf1, __isoc99_sscanf##GLIBC_2.7");
Now I'm left with the libcrypto dependency and it also looks like it's segfaulting on a munmap() (when i strace the program) function when I try to run it in the old OpenSuse environment (could be a GCC thing?)
So basically, I don't really know what the standard procedure is for fixing this kind of backwards compatibility issues. Any idea's on this?
Normally you would simply install the older gcc, glibc, and other libraries on the new OS (usually made available as RPMs for this reason) and make sure you compile only with those. It's an uphill battle to try to fix all the backwards incompatibilities yourself.
To be more thorough you could build in a chroot of the older OS, maybe even package it up into an RPM so the dependencies are automatically checked. Something like the Open Build Service makes this very easy.
Trying to follow the solution proposed in the answer to reducing haskell's binary question, I keep getting the error, when I install with --enable-shared option:
> cabal install opengl --enable-shared --reinstall
...
Could not find module `Prelude'
Perhaps you haven't installed the "dyn" libraries for package `base'?
Tried everything. I'm using apt-get installedhaskell-platform (with ghc 7.4.1), on Ubuntu 12.04, 64bit.
ANY tips?
It seems that Ubuntu's Haskell platform doesn't include dynamic libraries.
You can try installing ghc-dynamic, that should work, I assume the distro packagers know what they're doing. You would probably need to install the *-dynamic packages for several libraries included in the platform too.
In case it doesn't work, the only suggestions I can make is to compile GHC yourself from source (using the installed GHC), or use a vanilla GHC bindist, those come with dynamic libraries, as far as I'm aware.
Both would require reinstalling (recompiling included) the libraries, though (perhaps best to compile the vanilla platform from source then), so I recommend trying the distribution packages first.