I have been trying to install the tensorflow/haskell package on my Windows machine.
However, both while installing with stack and cabal, I keep running into this error:
Cabal-simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe: Missing dependency on a foreign
library:
* Missing C library: tensorflow
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
According to the Tensorflow website: https://www.tensorflow.org/install/install_c
, the C package for Tensorflow only runs on Unix machines. I am not sure if this is a dead end or if there is some workaround.
I am not experienced with linking libraries or with cabal, and would appreciate some assistance.
Using Cabal, I've included the following .cabal file in my directory:
cabal-version: >= 1.2
Executable hax
Includes: c_api.h
Extra-libraries: tensorflow
but I still receive the errors: cabal.exe: Missing dependency on a foreign library: * Missing C library: tensorflow The exception was: user error (Using 'build-type: Custom' but there is no Setup.hs or Setup.lhs script.)
You write "According to the Tensorflow website: https://www.tensorflow.org/install/install_c , the C package for Tensorflow only runs on Unix machines. I am not sure if this is a dead end or if there is some workaround."
Indeed, if you don't have the tensorflow C package installed on your machine -- because it won't run on it, then you can't find it to bind to it.
There is no work around for that.
I have never had this before but today I tried to use ghc and get:
could not find module
there are files missing in the base-4.10.0.0 package
ghc-pkg check returns:
https://pastebin.com/aCmr9igi
I had the exact same issue. Installing ghc-static fixed it.
You probably need to tell ghc to use shared libraries via the -dynamic flag, e.g.
$ ghc --make -dynamic path/to/file.hs
Doing this means you do not need to install the ghc-static package.
Try to tell ghc to build dynamically linked object files and executables, e.g., by
cabal install --dependencies-only --ghc-option=-dynamic
I've installed the Haskell Compiler and glpk-hs using the instructions here. Further, I've used cabal install glpk-hs to install required files in an attempt to compile a Haskell Program.
However, the cabal installation of glpk is not working. The following message keeps popping up:
Resolving dependencies...
Configuring glpk-hs-0.5...
Failed to install glpk-hs-0.5
Build log :
cabal: Entering directory '/var/folders/cr/9f1ltj7d4b31hmkfn03hjl_r0000gn/T/cabal-tmp-12521/glpk-hs-0.5'
Configuring glpk-hs-0.5...
cabal.real: Missing dependency on a foreign library:
Missing C library: glpk
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal:
Leaving directory '/var/folders/cr/9f1ltj7d4b31hmkfn03hjl_r0000gn/T/cabal-tmp-12521/glpk-hs-0.5'
cabal: Error: some packages failed to install:
glpk-hs-0.5 failed during the configure step. The exception was:
ExitFailure 1
As above, I have tried both installing glpk in a nonstandard location and the standard location, but in all cases, has been unable to find the glpk.
The glpsol solver, which uses GLPK is installed though, as it shows the version of which it is currently running: GLPSOL: GLPK LP/MIP Solver, v4.62
Figured it out! hmatrix-glpk had the extra directories for OS X in the .cabal file:
if os(OSX)
extra-lib-dirs: /usr/lib
extra-lib-dirs: /opt/local/lib/
include-dirs: /opt/local/include/
extra-lib-dirs: /usr/local/lib/
include-dirs: /usr/local/include/
if arch(i386)
cc-options: -arch i386
Copying this into the glpk-hs.cabal allows the installation to work.
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.)
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.