I need to install two packages, one depends on boost and the other depends on openmpi. The second package can be installed with cuda and cuda-aware openmpi. However I found the boost.mpi is not cuda-aware and if I install both software with different openmpi, they do conflict with each other. Can I install boost without boost.mpi?
I think that's the default
When Building From Source
E.g. on a fresh ubuntu container, doing
apt install -qy build-essential git cmake wget
wget https://boostorg.jfrog.io/artifactory/main/release/1.79.0/source/boost_1_79_0.tar.bz2
tar xf boost_1_79_0.tar.bz2
cd boost_1_79_0
./bootstrap.sh
./b2
Prints
...
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
...
In fact (one of?) the only Boost libraries affected would be PBGL (graph_parallel):
...
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam.
note: to suppress this message, pass "--without-graph_parallel" to bjam.
...
When Using Distribution Packages
On the same Ubuntu box, distribution-wide the only packages that depend on boost-mpi are:
libboost-mpi1.71.0
Reverse Depends:
libboost-mpi1.71-dev
rheolef
prime-phylo
librheolef1
libgyoto8
gyoto-bin
libboost-mpi-python1.71.0
libboost-graph-parallel1.71.0
Summary
Just don't install Boost MPI. That probably means not installing-the-kitchen-sink with
apt install libboost-all-dev
or the equivalent on your distribution. E.g. selectively install
apt install libboost-{regex,system,chrono}1.71-dev
Related
Using Windows 10 64-bit, Cabal-3.4.0.0, ghc-8.10.7.
I installed OpenBLAS in MSYS2 environment with command
pacman -S mingw-w64-x86_64-openblas.
Than, I successfully installed hmatrix-0.20.2 with command
cabal install --lib hmatrix --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib"
I am trying to build simple test project using cabal build cabalhmatrix with Main
module Main where
import Numeric.LinearAlgebra
main :: IO ()
main = do
putStrLn $ show $ vector [1,2,3] * vector [3,0,-2]
But now I am getting output
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
- hmatrix-0.20.2 (lib) (requires build)
- cabalhmatrix-0.1.0.0 (exe:cabalhmatrix) (first run)
Starting hmatrix-0.20.2 (lib)
Failed to build hmatrix-0.20.2. The failure occurred during the configure
step.
Build log (
C:\cabal\logs\ghc-8.10.7\hmatrix-0.20.2-6dd2e8f2795550e4dd624770ac98c326dacc0cac.log
):
Warning: hmatrix.cabal:21:28: Packages with 'cabal-version: 1.12' or later
should specify a specific version of the Cabal spec of the form
'cabal-version: x.y'. Use 'cabal-version: 1.18'.
Configuring library for hmatrix-0.20.2..
cabal-3.4.0.0.exe: Missing dependencies on foreign libraries:
* Missing (or bad) C libraries: blas, lapack
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.If
the library files do exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
cabal-3.4.0.0.exe: Failed to build hmatrix-0.20.2 (which is required by
exe:cabalhmatrix from cabalhmatrix-0.1.0.0). See the build log above for
details.
What should I do to correctly build that package?
I guess I need to somehow pass arguments --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib" to hmatrix during compilation, but don't know how to do that. To be honest, I don't understand for what program exactly are those arguments (cabal, ghc, ghc-pkg or something else) and why cabal is trying to install hmatrix again. I see hmatrix in directory "C:\cabal\store\ghc-8.10.7\hmatrix-0.20.2-e917eca0fc7690010007a19f4f2a3602d86df0f0".
Created cabal.project file:
packages: .
package hmatrix
flags: +openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
extra-lib-dirs: C:\\ghcup\\msys64\\mingw64\\bin, C:\\ghcup\\msys64\\mingw64\\libenter code here
After adding libopenblas.dll location to PATH variable cabal project is working.
Even though there is the --lib flag, it's generally best to work under the assumption that Cabal doesn't do library installs. Never install a library, instead just depend on it – and have Cabal install, update etc. it whenever necessary.
But then how can you pass the necessary flags? With a cabal.project file.
packages: .
package hmatrix
flags: openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
...
Put this file in the working directory of your own project, together with cabalhmatrix.cabal. Then running cabal build in that directory will use a hmatrix install with the suitable library etc. flags.
I'm desperately trying to compile Tesseract-ocr (4.0) on a Windows Machine with some restrictions.
We are doing multi-platforms : an automated compilation must be possible (command-line)
We are using specific 3rd party libraries : the compilation must accept custom path / libraries for most of its dependencies
We are already using most of the 3rd party libraries for other part of the code : the compilation must not recompile them (thus, no cppan)
Leptonica has been built with our special 3rdparty (ZLib, LibPng ..)
Our project must "include" tesseract alongside theses specific 3rdparty
Problem :
I have strong issue specifying custom paths for Tesseract.
Under Unix (CentOS, Ubuntu 16/18, Debian 8/9 ..), I was able to achieve my goal with the tools autogen autoconf autoheaders pkg-config.
Under Windows, autoconf-archive and pkg-config are unavailable (from what I tried) ; rendering autoconf unusable.
I was neither able to compile using CMake and specifying a custom path for Leptonica (even after writing a new pkgconfig for leptonica).
Things I tried :
Using MinGW and autoconf
Manually installing pkg-config
Cheating with autoconf-archive .m4 into aclocal
Creating a VisualStudio project with cppan and modify it
Various ways of telling CMake to search elsewhere for 3rdparty
Things that work on Linux :
Autoconf with modified PKGConfig for custom compiled Leptonica (--with-extra-libraries PKG_CONFIG_PATH CPPFLAGS LDFLAGS)
Things I have not tried :
Installing Leptonica on the machine (Not the point here)
Rewriting CMakeFiles
Unknown solutions ?
Possible Solutions
MinGW (Windows) with pkg-config autoconf-archive
Unknown way to tell CMake Leptonica custom path
VisualStudio project without cppan
Yours ?
Thank your for your interest.
EDIT 1
By trying various ways of manually installing pkg-config, Autoconf seemed to be unaware of its presence. This error was about pkg-config missing package (How to install pkg config in windows?).
CPPAN was deeply part of the visual studio project and I couldn't see how I could separate them.
I usually tell configure to look for leptonica package with the arguments --with-extra-libraries and PKG_CONFIG_PATH.
CMake however, uses the "macro" find_package(Leptonica $PATH CONFIG REQUIRED). By looking at it a little bit, I was (maybe) able to specify its path with CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH, Leptonica_DIR. The compilation was still unsuccessfull due to missing config files (LeptonicaConfig.cmake or leptonica-config.cmake).
I pointed theses variables to various folders of the leptonica folder after building it.
For information, I built Leptonica with its configure as such :
bash configure --enable-shared=false --without-giflib --without-libwebp --without-libopenjpeg LDFLAGS="-LPATH/TO/ZLIB -LPATH/TO/LIBPNG .." CPPFLAGS="-IPATH/TO/ZLIB/INCLUDE ..."
I, however, was unable to locate theses files (while seeing a LeptonicaConfig.cmake.in under LeptonicaDir/cmake/template)
I hope I answered your questions. Please tell me if you need further details.
To compile tesseract-4.0.0 on Windows with MSYS and MinGW:
Prerequisites:
Download Tesseract OCR 4.0: https://github.com/tesseract-ocr/tesseract
Install MSYS2 (msys2-x86_64): https://www.msys2.org/
Extract tesseract-4.0.0.zip to C:/msys64/home/tesseract/tesseract-4.0.0
Open Start Menu > MSYS2 64bit > MSYS2 MSYS and run the following commands:
$ pacman -Syu
#### Close terminal window and open it again (MSYS2 MSYS) ###
$ pacman -Su
$ pacman -S base-devel
$ pacman -S mingw-w64-i686-toolchain
$ pacman -S mingw-w64-x86_64-toolchain
$ pacman -S mingw-w64-i686-cmake
$ pacman -S mingw-w64-x86_64-cmake
32-bit Compilation:
Open Start Menu > MSYS2 64bit > MSYS2 MinGW 32-bit and run the following commands:
$ cd /home/tesseract/tesseract-4.0.0
$ pacman -S mingw-w64-i686-leptonica
$ ./autogen.sh
$ ./configure --prefix=/home/tesseract/install/windows-i686
$ make -j4
$ make install
64-bit Compilation:
Open Start Menu > MSYS2 64bit > MSYS2 MinGW 64-bit and run the following commands:
$ cd /home/tesseract/tesseract-4.0.0
$ pacman -S mingw-w64-x86_64-leptonica
$ ./autogen.sh
$ ./configure --prefix=/home/tesseract/install/windows-x86_64
$ make -j4
$ make install
The compiled tesseract will be installed on: C:/msys64/home/tesseract/install
The last days I struggled with libraries (GLib2.52.2 & GTK3.22.15), while I tried to compile them on Ubuntu 16.04 LTS (fresh installation).
The GLib2.52.2 just compiled without errors after installing the needed dependencies.
My problem is following:
when I want to start compilation of GTK3.22.15
$ ./configure --prefix=/usr --with-pcre=system && make -j 6
I get this error message:
configure: error: Package requirements (glib-2.0 >= 2.49.4 atk >= 2.15.1 pango >= 1.37.3 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gdk-pixbuf-2.0 >= 2.30.0) were not met:
Requested 'glib-2.0 >= 2.49.4' but version of GLib is 2.48.2
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables BASE_DEPENDENCIES_CFLAGS
and BASE_DEPENDENCIES_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
SOLVED EDIT
I got a suggestion from AskUbuntu to compile everything in /usr/local to prevent conflicts, in some cases with official repository updates.
$ ./configure --prefix=/usr/local --with-pcre=system && make -j 6
Did solve my problem under these conditions. I didn't touch anything more, referring to the other so said "not matching" dependencies, to compile GTK3 (3.22.15) after recompiling GLib2.0 (2.52.2) in /usr/local.
Requested 'glib-2.0 >= 2.49.4' but version of GLib is 2.48.2
When compiling libraries for Gnome or Gtk, you frequently have to update other libraries too. If you download gtk3 from the ubuntu repositories (use the synaptic package manager to search for gtk3 or gtk+-3.0), you will see that you will not only download gtk3, but a pile of other libraries gtk3 needs. In case of using the repositories (recommended!) the system will take care of everything.
I'm not an Ubuntu user, but I am interested in the behind-the-scenes part, so I frequently compile libraries, and I have to do this manually. So, to install a new version of gtk3, I have to first compile and update glib. After doing so, I might also have to update Pango, ATK, and several other libraries first. If you like losing time with such stuff, go for it! Else consider using the repositories.
I use the following autotool steps to install my pacakges:
./configure
make
make install prefix=/my/path
However I got the following libtool warning "libtool: warning: remember to run 'libtool --finish /usr/local/lib' and "libtool: warning: 'lib/my.la' has not been installed in '/usr/local/lib'" when using the autotool to install my software package. If I change to the following command, the problem disappear:
./configure
make prefix=/my/path
make install prefix=/my/path
It looks like the first method doesn't substitute the prefix correctly to libtool. How can I avoid this problem?
Among the information that libtool archives record about the libraries they describe is the expected installation location. That information is recorded when the library is created. You can then install to a different location, but libtool will complain. Often, libtool's warning is harmless.
In order to avoid such a warning, you need to tell libtool the same installation location at build time that you do at install time. You present one way to do that in the question, but if you're using a standard Autotools build system then it is better to specify the installation prefix to configure:
./configure --prefix=/my/path
make
make install
Alternatively, if you're installing into a staging area, such as for building an RPM, then use DESTDIR at install time. libtool will still warn, but you'll avoid messing up anything else:
./configure
make
make install DESTDIR=/staging/area
I was following an online tutorial to install some Python modules using homebrew and one step was to install gfortran with brew install gfortran. Later on, I tried using another third-party installation script to install some Python modules and after the fact I realized that part of what the script did was download and run http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg. I don't know that much about gfortran, but looking at the brew formula for gfortran it appears that brew uses a different version from the att.com one. Will that lead to problems in the future? I did brew uninstall gfortran and brew install gfortran again, and so far it seems like things are the same (I tried recompiling the old code that I had compiled before), but I am not sure what all the att.com pkg did. (I have OS X 10.8.2 and XCode 4.2 if that matters).
It depends on where the other gfortran installer goes to. In general, no, it won't conflict. * Homebrew is designed to be compatible with third-party gfortran installs - it defines dependencies on a generic "fortran" compiler, and not on the specific gfortran Homebrew formula. Homebrew stays under /usr/local, sticking the main install in /usr/local/Cellar, and symlinking judiciously in to /usr/local/lib. Other installers that install to /usr/local will just prevent Homebrew from linking its own compiler in, but will work with other formulas that use a fortran compiler. (Assuming the gfortran build options are compatible.)
That particular gcc-42 installer you linked to installs to /usr, not to /usr/local.** And its binaries are suffixed with "-4.2"; that is, it installs cpp-4.2, g++-4.2, gfortran-4.2, and so on. So a) there's no direct conflict with the Homebrew gfortran, and b) it won't directly shadow the /usr/local/bin/gfortran installed by Homebrew.
Which compiler will get picked up by things you build with both these gfortrans installed will depend on how the build works, but most will be looking for plain gfortran and so will find the Homebrew one, unless you explicitly direct them to the AT&T-provided one. You don't specify how you're building things, but since you're using brew, I'm assuming it's via brew or command line tools, in which case I think they're all probably seeing the Homebrew gfortran and ignoring this one. Look at the verbose output from their build processes to find out for sure.
*Depending, of course on what you mean by "conflict".
**Side note: AFAIK there's no easy way to figure this out by looking at the package or an installation manager. I just did a find /usr before and after running that installer, and did a diff on the output:
$ diff usr_before_any_installs.txt usr_after_att_install.txt | grep '^[<>]'
> /usr/bin/c++-4.2
> /usr/bin/cpp-4.2
> /usr/bin/g++-4.2
> /usr/bin/gcc-4.2
> /usr/bin/gfortran-4.2
> /usr/bin/i686-apple-darwin11-cpp-4.2.1
> /usr/bin/i686-apple-darwin11-g++-4.2.1
> /usr/bin/i686-apple-darwin11-gcc-4.2.1
> /usr/bin/i686-apple-darwin11-gfortran-4.2.1
> /usr/include/gcc
> /usr/include/gcc/darwin
> /usr/include/gcc/darwin/4.2
...