Is it possible to change cabal or GHC settings so that cabal install generates dynamic binaries and libraries by default?
I'm using GHC 8.2.2, installed using apt-get in Ubuntu (16.04) without Haskell Platform or stack. Searching around, I found the SO question Why can't cabal build mighttpd2 dynamically? . The answers/comments there said something about adding --enable-shared --enable-executable-dynamic when cabal install. And this can be done manually for all dependency libraries (which would be a pain).
In Small Haskell program compiled with GHC into huge binary, the accepted answer says that one needs to:
cabal install some_package --enable-shared --reinstall
The option -dynamic is also mentioned.
My question is:
Is it possible to change the options in the cabal configuration file (~/.cabal/config) from the very beginning so that all binaries and their dependency libraries use dynamic linkage (i.e. with --enable-shared --enable-executable-dynamic or -dynamic by default)?
Indeed, you can alter your ~/.cabal/config file to have the following lines:
shared: True
executable-dynamic: True
I'm trying to compile a Haskell source package as a dynamic library to be used with OCaml code. I tried using the --enable-shared option with cabal install on the .cabal file of the source, I got a Perhaps you haven't installed the "dyn" libraries for package 'zeromq4-haskell-0.6.5' error. After a little googling, I realised that the dependencies must also be compiled as dynamic libraries. I downloaded the source package for zeromq and tried installing the zeromq package with the --enable-shared option. This time I got a similar error with one of zeromq's dependencies. I tried doing this 4-5 times and get an error with a different dependency at each level.
Am I making a mistake here? How can I get all of the dependencies to install as dynamic libraries?
Thanks!
If you generally want to have shared libraries, you can permanently enable it in your .cabal/config:
shared: True
However, it will only affect libraries installed after that, so you may want to purge all libraries and start over again.
If this is just a one-shot, you may create a cabal sandbox just for that purpose:
cd yourlib
cabal sandbox init
cabal install --enable-shared
The result will be in the directory .cabal-sandbox.
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.
Trying to install MFlow on linux mint. sudo cabal install MFlow gives me this:
Loading package primitive-0.5.3.0 ... : can't load .so/.DLL for: libHSprimitive-0.5.3.0.so (libHSprimitive-0.5.3.0.so: cannot open shared object file: No such file or directory)
Failed to install vector-0.10.9.2
cabal tells me that I do have primitive-0.5.3.0 installed. Any hope of getting this to happen?
Thanks much for any help!
I ran into the exact same issue. So here's some elaboration on the problem.
The comment by user2407038 provided the answer. By default, shared is set to False so shared libraries are not built. This means any libraries that expect to link to the shared library libHSprimitive-*.so would fail to build.
The solution was to reinstall primitive with shared set to True. You can do this either by modifying ~/.cabal/config or by passing an extra argument:
cabal install --reinstall --enable-shared primitive
I am trying to build Guile 1.8.8 from source. I am stuck at the point where the build system is looking for libtool. I have installed it in a non-standard location.
I have already built Guile 2.0.11. In 2.0.11 build system, there is an explicit flag to configure --with-libltdl-prefix, which I think tells the build system where libtool is installed.
For Guile 1.8.8, I have Libtool installed in a non-standard location. How do I tell the build system where it is installed?
I am specifically getting error messages like:
libguile/Makefile.am:40: Libtool library used but `LIBTOOL' is undefined
libguile/Makefile.am:40: The usual way to define `LIBTOOL' is to add `LT_INIT'
I think in general this is a question regarding one or more of the autotools and how the build system finds programs / headers / libraries in non-standard locations.
This link is informative: How to point autoconf/automake to non-standard packages
Find the directory where *.m4 exists, which corresponds to libtool, or package which is in non-standard location.
export ACLOCAL_PATH=/path/to/m4/file
cd /path/to/configure.[in,ac]
autoreconf -if
./configure