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
Related
Hi, All
I am currently installing the openmpi-4.1.1 on ubuntu18.04 from the tar.gz file.
However, when I use the nvcc (CUDA 11.2.2) compiler with -lmpi_cxx, it reports that this linking option does not exist.
is there anything wrong when I am building and installing the openmpi?
I use the following commands when building openmpi with CUDA-aware capability.
./configure --with-cuda
make -j8 install
I try to remove -lmpi_cxx and only keep -lmpi, the compiler reports errors like
undefined reference to `MPI::Comm::Comm()'
Thanks a lot!
I just figure this out by myself.
I need to enable the c++ binding of the MPI when building the openmpi.
Here are the commands
./configure --enable-mpi-cxx --with-cuda
make all install
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
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.
I'm updating my yesod framework to the latest yesod 1.2 version. I've installed yesod-platform (painfully....had to manually delete old dependency....cabal hell), now I need to install yesod-bin and it should be done. However, after sudo cabal install yesod-bin I'm getting the following error.
Building yesod-bin-1.2.0...
Preprocessing executable 'yesod-ld-wrapper' for yesod-bin-1.2.0...
[1 of 1] Compiling Main ( ghcwrapper.hs, dist/build/yesod-ld-wrapper/yesod-ld-wrapper-tmp/Main.o )
Linking dist/build/yesod-ld-wrapper/yesod-ld-wrapper ...
/usr/bin/ld: cannot find -lHStar-0.4.0.1
/usr/bin/ld: cannot find -lHSoptparse-applicative-0.5.2.1
/usr/bin/ld: cannot find -lHSghc-paths-0.1.0.9
/usr/bin/ld: cannot find -lHSfsnotify-0.0.6
/usr/bin/ld: cannot find -lHShinotify-0.3.5
collect2: ld returned 1 exit status
Failed to install yesod-bin-1.2.0
cabal: Error: some packages failed to install:
yesod-bin-1.2.0 failed during the building phase. The exception was:
ExitFailure 1
According to this, I feel it may have something to do with privileges I'm not sure.
EDIT: So I only found the following two libraries.
/usr/lib/haskell-packages/ghc/lib/tar-0.3.2.0/ghc-7.4.1/libHStar-0.3.2.0.a
/usr/lib/haskell-packages/ghc/lib/ghc-paths-0.1.0.8/ghc-7.4.1/libHSghc-paths-0.1.0.8.a
I'm trying to update libghc-tar-dev to the newest version 0.4.0.1. However, 0.3.2.0 is the newest version on apt-get what are my options?
First, I'd check to see if you have the libraries libHStar, libHSoptparse-applicative, libHSghc-paths, libHSfsnotify and libHShinotify. If you installed the haskell platform using your distro's package manager, I suspect you'll find those libraries in /usr/local/lib/ghc-*.*.*/. For example, you might search for the first library using this command:
sudo find /usr/local/lib -name 'libHStar*'
If you don't have those libraries, then I think you can get them by using your distro's package manager to install the following:
libghc-tar-dev
libghc-optparse-applicative-dev
libghc-ghc-paths-dev
libghc-fsnotify-dev
libghc-hinotify-dev
If you already have those libraries, then you could adapt the fix suggested in your link:
sudo chmod a+r /usr/local/lib/ghc-*/libHS*
UPDATE:
The standard recommendation seems to be that you should always use your linux distro's package manager to install stuff, rather than using the cabal command directly. And if a package you want isn't available yet on your distro, request it. This approach is the safest, because all of the dependencies have been sorted out for you. The disadvantage is that you won't usually have the latest release. I see that there is a yesod package on Ubuntu. I have no idea if it contains yesod-bin (I'm not familiar with yesod), but if it does, that's the safest approach. The downside is that you will probably have to wipe out your cabal library and start from scratch (re-install haskell-platform, then yesod).
Another option, which seems to be the road you're on, is to use your package manager to install the haskell-platform, but after that use the cabal command to install any haskell-y stuff. You'll still use your package manager to install things that can't be installed using cabal (e.g., non-haskell stuff). If you do this, you can avoid a lot of cabal hell by never running cabal as root, and never letting your package manager do anything that can be done using cabal. The main disadvantage of this approach is that you have to deal with library dependencies yourself, as you've discovered. If you want to continue down this road, you might be able to get everything you need by switching to some development/test build for Ubuntu. Or you may have to get the correct versions of the libraries you need and manually install them.
I am trying to cabal install yesod on my Windows machine. I have a relatively fresh install of the Haskell Platform. The cabal install failed, reporting that I need the sqlite3 C library in order to install "persistent", a package which Yesod relies upon.
cabal: Missing dependency on a foreign library:
* Missing C library: sqlite3
So I went to http://www.sqlite.org/download.html and grabbed both the C source and the precompiled binary. I tried using both, to no avail:
cabal install persistent --extra-lib-dirs=C:\Path\To\C\Source\Files
cabal install persistent --extra-lib-dirs=C:\Path\To\Binary
In both cases, I got the same result: it didn't work. :( What can I do to give cabal the C library it needs? (sqlite3 in this case)
So, facepalm. I didn't need the source, I didn't need the exe. I needed the dll.
Under the "precompiled binaries for Windows" section of the website mentioned in my question, I downloaded and extracted the zip file with sqlite3.def and sqlite.dll. Then I used
cabal install persistent --extra-lib-dirs=C:\Path\To\DllAndDef
The installation appears to have completed successfully. Afterwards, I did a cabal install yesod, which also appears to have completed successfully.
I suppose if I had put the dll somewhere magical, then I wouldn't have had to use the --extra-lib-dirs= option.