I'm attempting to compile a Haskell project on Windows with profiling enabled, using the following command.
ghc --make -O -prof -fprof-auto game_dangerous.hs
I develop the project myself and the same source code compiled and linked fine without profiling. As expected (from previous experience) I ran into a number of errors of the form:
Could not find module `Data.Vector.Mutable'
Perhaps you haven't installed the profiling libraries for package `vector-0.12.0.2'?
I proceeded to iteratively reinstall packages based on the errors encountered using for example:
cabal install -p vector --reinstall
Cabal kept giving me warnings about possibly breaking packages with the reinstalls but I pressed on as (as far as I could see) every package that could be broken was going to get reinstalled itself as I moved through the tree of dependencies. Also, I've previously followed the same process on another machine and it worked fine. After reinstalling all the required packages my project now compiles but the linker fails with this error:
C://Program Files//Haskell Platform//8.6.3//mingw//bin/ld.exe: cannot find -lHSsemigroups-0.18.5-8pPnWqWrcWhEagTFf5Pnk2_p
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
However, the build does complete successfully without profiling enabled. Does anyone know what may have gone wrong and how to fix the issue? Thanks in advance.
Steven
I would try making a .cabal file for your program, where you explicitly specify the cabal packages your program depends on and use cabal v2-build to compile your program. It will warn you about missing dependencies of your program until you include them all in build-depends section of the .cabal file. You only need to include the dependencies of your program, not the dependencies of the dependencies. After that you can add cabal.project.local to enable profiling and maybe something else. It should be enough to run cabal v2-build to build your program and packages it depends on with profiling(and other options in the cabal.project.local) enabled.
You need to have profiling enabled in the packages used by your program to support profiling in it. Cabal v2 builds allows you to have multiple instances of the same package. Those instances are different because different flags and options have been used to build them.
It is possible to achieve the same result using a separate package database for your program. That is using ghc-pkg with --package-db option.
Another option is to use stack. It will solve the same issues, but differently at the cost of more space and some performance penalties in ghc(compared to ghc built from source which can be used with cabal).
Related
I'm trying install tidal in command line this way:
cabal install tidal
but it ends with this message:
Warning: You asked to install executables, but there are no executables in
target: tidal. Perhaps you want to use --lib to install libraries instead.
Return of:
cabal install tidal --lib
is:
Resolving dependencies...
Up to date
If I check ghk-pkg list, there is no package tidal
...
Have somebody similar problem or what I'm doing wrong?
My environment is:
Windows 10 Education
Haskell 8.4.3
Cabal 3.2.0.0
Ghc 8.10.1
Thank you for help.
Like Stack for a longer time, Cabal-install does now (as of 3.2) not really install libraries anymore – in the sense of, change the computer's state so that GHC can access the library on it†. Both tools only install executables now. It used to do that for libraries too, but that was stopped with the now default Nix-style builds.
Now (and, really, also already before), the way to use a library is instead to just depend on it, and let Cabal figure out behind the scenes if it needs to be installed. I.e., you add a .cabal file to your .hs source file with build-depends: tidal in it. Then when you say cabal install ., it will first download and install the library before then using it for building your own executable.
†Of course both Stack and Cabal do technically speaking install libraries, just they don't globally register them. I.e., cabal knows where it has installed the library, but you're not really supposed to know about that. It's in the spirit of continuous integration: if your code builds now with the particular state of libraries you happen to have installed, that's not very reliable. If it builds with just those libraries that are explicitly listed in a project file, the chances are much better that future-you (or somebody else) will still be able to use your code on another computer without hours of figuring out what libraries to install first.
cabal install --lib tidal doesn't install the library binaries in a location managed by ghc-pkg. The binaries remain in the Cabal "store".
What it does is to create a plaintext GHC package environment file that is picked up by standalone invocations of ghc and ghci and tells them where to look for the extra libraries.
By default (as mentioned in the docs) this package environment file will be created at ~/.ghc/$ARCH-$OS-$GHCVER/environments/default and will be picked by ghc and ghci invocations made anywhere.
We can also supply an extra --package-env parameter to create the environment file in a local folder, which will only affect ghc and ghci invocations made in that folder. For example:
cabal install --lib --package-env . tidal
cabal projects themselves ignore environment files, as their package environments are constructed from the build-depends section of the cabal file for the sake of reproducibility. But environment files are useful for not having to create a cabal project in the first place, if you only need it for playing with the library in ghci, or if you are compiling simple programs using ghc only.
I'm trying to install ghc-mod for GHC 8.0.1 on windows/x64. When I try to install ghc-mod via cabal install ghc-mod I get an error saying my C compiler isn't working (it is using the c-compiler bundled with ghc).
Here is the output (of the second time I ran the command. Its basically what the first one says but reduced to the error message):
C:\Users\******>cabal install ghc-mod
Resolving dependencies...
Configuring old-time-1.1.0.3...
Failed to install old-time-1.1.0.3
Build log ( C:\Users\******\AppData\Roaming\cabal\logs\old-time-1.1.0.3.log ):
Configuring old-time-1.1.0.3...
bash.exe: warning: could not find /tmp, please create!
configure: WARNING: unrecognized options: --with-compiler
checking for gcc... C:\PROGRA~1\Haskell Platform\8.0.1\mingw\bin\gcc.exe
^ I think the error lies here, as you can see the file path is corrupted but I wasn't able to locate the cause for this
checking whether the C compiler works... no
configure: error: in `/cygdrive/c/Users/******/AppData/Local/Temp/cabal-tmp-6084/old-time-1.1.0.3':
configure: error: C compiler cannot create executables
See `config.log' for more details
cabal: Leaving directory 'C:\Users\******\AppData\Local\Temp\cabal-tmp-6084\old-time-1.1.0.3'
cabal: Error: some packages failed to install:
cpphs-1.20.2 depends on old-time-1.1.0.3 which failed to install.
ghc-mod-5.6.0.0 depends on old-time-1.1.0.3 which failed to install.
haskell-src-exts-1.17.1 depends on old-time-1.1.0.3 which failed to install.
hlint-1.9.35 depends on old-time-1.1.0.3 which failed to install.
old-time-1.1.0.3 failed during the configure step. The exception was:
ExitFailure 77
Could you please help me to install ghc-mod or provide any other way of installing it.
I already trieded reinstalling Haskell since I'm just starting off but this didn't make any difference.
And YES I added the 3 lines provided on the haskell homepage.
I can't know for certain, but thought I'd write an answer with what I think is going on.
The old-time package contains a configure script, which is a Unix shell script used to (surprise!) configure the package. The Cabal build system allows packages to automatically integrate configure, and will run the script for them. On POSIX systems, there's always a shell easily available. However, on Windows, that's not the case. I believe that's the problem you're running into.
Now the tricky part: why don't you have a shell? In theory, the Haskell Platform ships a shell. Well, here are my guesses:
For Stack usage, there's a Haskell Platform bug where Stack cannot find the MSYS tools, which include the shell script. Newer versions of Stack work around this bug, but passing in --no-system-ghc tells Stack to ignore any installed toolchain and manage the installation itself, which is more reliable than using HP's copy.
For Cabal usage, I'm less certain. I think the HP team decided to require you to use a special batch program to set environment variables correctly, so if you just run cabal install foo from a normal command window, Cabal won't find MSYS and it will fail. However, without more information, I can't be certain this is the case.
My personal recommendation: uninstall Haskell Platform, and use the recommended Stack installation instructions. In your case, that's just downloading and running the 64-bit Windows installer.
Finally: your suspected problem is not actually a problem; on Windows, pathnames longer than 8 characters can be compressed in the way you see (with ~1 at the end). There's nothing buggy in that path display.
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've installed ghc 6.12.3, and then the Haskell Platform. I'm trying to compile a test program:
$ ghc test.hs
test.hs:3:0:
Failed to load interface for `Bindings':
Use -v to see a list of the files searched for.
so, naturally, I do
cabal install Bindings
Which works fine, and places the package in ~/.cabal/lib/bindings-0.1.2 The problem is, that when I go to compile again with ghc, it still doesn't find the package I've installed with cabal.
compiling in verbose mode gives:
ghc -v test.hs
Using binary package database: /home/ludflu/ghc/lib/ghc-6.12.3/package.conf.d/package.cache
Using binary package database: /home/ludflu/.ghc/x86_64-linux 6.12.3/package.conf.d/package.cache
As suggested by another stackoverflow user, I tried:
ghc-pkg describe rts > rts.pkg
vi rts.pkg # add the /home/ludflu/.cabal/lib to `library-dirs` field
ghc-pkg update rts.pkg
But to no avail. How to I add the .cabal to the list of package directories to search?
Thank you!
You can check which packages are installed with ghc-pkg list. It may be that you need to either specify the packages to ghc with -package <pkgname> or I believe adding --make to will trigger a chasing down of dependencies, including packages.
Edit: the bindings package is obsolete indeed, see the hackage page. This isn't a package management problem, the only module available is Bindings.Deprecated, which you are perfectly able to load, even though it is an empty module. I believe the relevant parts have been broken out into bindings-<module>, so if you want the bindings functionality you should look to those packages.
http://www.haskell.org/haskellwiki/Cabal-install
One thing to be especially aware of, is that the packages are installed locally by default by cabal, whereas the commands
runhaskell Setup configure
runhaskell Setup build
runhaskell Setup install
install globally by default. If you install a package globally, the local packages are ignored. The default for cabal-install can be modified by editing the configuration file.
I was getting the same error with the runhaskell command. I used the cabal in the directory that had the .cabal file and was able to resolve the error.