I try to compile Octave 3.8.2 on CentOS 6.4 （serve）, but there's an error:
A BLAS library was detected but found incompatible with your Fortran 77 compiler settings.
I'm so confused. I compiled a BLAS and a LAPACK myself, and I added their path to bashrc. But this error appeared again. I try to change fflags to ff2c as other resources suggested, but this error also occurred.
I found the following guide and discussion of my error.
I am going through this, and I had the same issues that you are mentioning. I solved it by using the auto config options to point it to the correct library, e.g.
./configure --with-lapack=/path/to/liblapack.so.3 --with-blas=/path/to/libf77blas.so.3
It compiles and produces an executable.
I would suggest using OpenBLAS instead of the common BLAS and LAPACK packages. It is written in the Octave documentation:
"Accelerated BLAS libraries such as OpenBLAS (https://www.openblas.net/) or ATLAS (http://math-atlas.sourceforge.net) are recommended for best performance. The reference implementation (http://www.netlib.org/blas) is slow, unmaintained, and suffers from certain bugs in corner case inputs."
You can download it from https://www.openblas.net/ and install it with the classical ./configure && make %% sudo make install. After this move the libraries generated by OpenBLAS to /usr/lib64 and run:
./configure -with-blas="-lopenblas"
Add other flags and arguments to configure if needed.
Related
I have been trying to compile an old Python code. A couple of days ago I posted a question that described problems with accessing Python and gfortran. I solved the Python problem, then the question no longer made sense. It had no answers so I deleted it. However, now when I run a "configure" script, I'm getting an error that I don't understand:
configure: error: You need to set PETSC_DIR to point at your PETSc installation... exiting
An online search to find out what PETSc is turned up a forum post (https://github.com/firedrakeproject/firedrake/issues/1703) that mentions "gfortran" and I wonder that's where my problem is. I installed gcc via Homebrew to get gfortran and now see it at /usr/local/bin/gfortran. In my .zshrc file, I added:
export PATH=$PATH:/usr/local/bin
alias python=/usr/local/bin/gfortran
When I do:
gfortran --version
I get (which seems fine):
GNU Fortran (Homebrew GCC 11.3.0_2) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When I do:
which gfortran
I get the following.
aliased to gfortran -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
The other thing that seems relevant is that I just did:
brew install openmpi
to overcome an error related to not having MPI. I don't know anything about using MPI on a Mac so it's likely this is where I'm going wrong.
configure: error: no MPI support found on system
Here are the clues from the "configure" script log file:
checking for malloc in -ltcmalloc... no
configure: WARNING: No tcmalloc support available.
checking for mpif90... no
checking for mpf90... no
checking for mpicc... no
checking for mpcc... no
checking for mpicxx... no
checking for mpiCC... no
checking for mpCC... no
checking if we can compile and link without using -lmpi... no
checking if we can compile and link using -lmpi... no
checking if we can compile and link using mpich libs... no
configure: error: no MPI support found on system
I would be very grateful if someone could please point me in the right direction.
Your error message indicates that the PETSc library is missing. You can probably find a pip installation that gives you petsc with a python interface.
However, your further problem with Zoltan indicates that (probably) you need a petsc installation that has zoltan as optional package. I'm not sure that you can find a pip install for that. You may need to install petsc entirely by hand.
https://petsc.org/release/install/
and use the configuration options --with-zoltan --with-mpi4py.
I'm trying to Install BLAS on my Mac, but every time I run make I get this error (shown below the link). I was trying to follow the instructions on this website:
gfortran -O3 -c isamax.f -o isamax.o
make: gfortran: No such file or directory
make: *** [isamax.o] Error 1
I have no idea what this means or how to fix it so any help would be appreciated. Also I'm trying to install CBLAS and LAPACK so any tips/instructions for that would be nice if you know of a good source...Everything I've found so far is pretty confusing. Also I tried to install ATLAS but it kept not working.
This error is caused because gfortran is apparently not installed, so you'll need to download an installer package for OS X Yosemite 10.10 and install it:
gfortran 5.1 or
gfortran 4.9.2 (info)
Once installed run the make command in the BLAS directory.
How to install Blas/Lapack: don't.
These libraries are the textbook example of enormous performance differences between simple and optimized code. And by optimizations I don't mean compiler: I mean algorithm transformations.
So you definitely do not want to download the "reference blas/lapack" from netlib or another location. If your system doesn't already come with an optimized version (Mac OS X does), see if you can get Intel's MKL library (free for students on Linux?), and otherwise get BLIS or OpenBlas or Atlas which are all open source optimized implementations.
I'm having trouble building the hmatrix library on OS X Lion. Looking at the .cabal file, it requires the gsl library, so I installed it with macports. The .a files are in /opt/local/lib and the .h files are in /opt/local/include/gsl
As suggested here I changed the built-type from Custom to Simple. (without that change I get a similar error).
When I use cabal configure I get the following output:
* Missing C library: gsl
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.
So I tried cabal --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib configure, but I still get the same error. I can compile and link a c program that includes gsl. What files is cabal looking for? If I have the right files, how do I tell it how to find them?
libgsl.a is a universal binary:
$ file /opt/local/lib/libgsl.a
/opt/local/lib/libgsl.a: Mach-O universal binary with 2 architectures
/opt/local/lib/libgsl.a (for architecture x86_64): current ar archive random library
/opt/local/lib/libgsl.a (for architecture i386): current ar archive random library
ghc looks like it's 64-bit:
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/llvm-gcc")
,("C compiler flags"," -m64 -fno-stack-protector -m64")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has subsections via symbols","True")
,("Project version","7.4.2")
,("Booter version","7.4.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2")
,("Global Package DB","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d")
,("Gcc Linker flags","[\"-m64\"]")
,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
]
As an alternative to mac-ports you can use the nix package manager for mac. It does a pretty good job of taking care of the c dependancies for for the libraries available through it. In general I have been more happy with it then any other package manager on mac.
Unfortunately mac(darwin) unlike for linux does not have as many binaries available through nix so installing ghc often means waiting for it to compile.
The commands to install ghc and hmatrix after installation of nix are:
nix-env -iA nixpkgs-unstable.haskellPackages.ghc
nix-env -iA nixpkgs-unstable.haskellPackages.hmatrix
All of the needed dependencies will be taken care of for you.
I just tried it on my macbook pro and hmatrix seems to be working correctly in ghci after trying commands from the first few pages of the tutorial.
I'm not a mac person, but it really sounds like you haven't installed the "-dev" version. For a mac, I suspect you need to install gsl-devel in addition to gsl. If the problem persists, verify that you have libgsl0-dev on your library path.
According to this post (https://github.com/mxcl/homebrew/pull/2953), the flag "--with-mpi" should enable boost_mpi build support for the related homebrew formula, so I am trying to install boost via homebrew like this:
brew install boost --with-mpi
However, the actual boost mpi library is not being build and can not be found.
There is currently some work being done around this, according to: https://github.com/mxcl/homebrew/pull/15689
In summary, I can currently build boost, but it seems the "--with-mpi" flag is being ignored. Could someone please check, if I should be able to build boost (with mpi support) on Mac OS X Mountain Lion (10.8)?
The (verbose) output generates these lines:
MPI auto-detection failed: unknown wrapper compiler mpic++
Please report this error to the Boost mailing list: http://www.boost.org
You will need to manually configure MPI support.
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.
Not sure how exactly I can fix this and get the mpi stuff to be build - any ideas?
Just in case this helps anyone else along the line, here's how I fixed this. The main error is MPI auto-detection failed: unknown wrapper compiler mpic++, any typing mpic++ at the command line verified that it was not working properly for me. I used brew to install open-mpi, but the same error was showing in the verbose output for installing boost. A run of brew doctor showed that openmpi was not linked properly, so I fixed those errors and reran brew -v install boost --with-mpi --without-single and it finally built and installed all of the libraries without a problem
To anyone that comes across this, the package migrated to boost-python and boost-mpi separate from boost. Use brew install boost-mpi
Just get it worked on OSX 10.11.5. I've tried brew, but with no luck.
Suppose you already have gcc installed. Here are what I've done:
1. Find and disable (but do not remove) clang
clang alway cause headaches. There would be a lot of warnings when building Boost.
which clang, which should give you /usr/bin/clang
Rename it: sudo mv clang clang_mac_remove, also for clang++: sudo mv clang++ clang++_mac_remove. You can change the names back if you need them in future.
2. Install OpenMPI
If you already installed using brew, uninstall first. Becasue it would have used clang as the compiler wrapper by default. You need to change the wrapper to gcc.
Download the package.
Specify the wrapper compiler to gcc and g++:
./configure CC=gcc CXX=g++ F77=ifort FC=ifort --prefix=/usr/local
Below may take a long time.
make all
sudo make install
Reference: https://wiki.helsinki.fi/display/HUGG/Open+MPI+install+on+Mac+OS+X
3. Install Boost MPI
Download the package.
Run ./bootstrap.sh (can open it first and specify the toolset to gcc, otherwise, the default option is darwin for mac).
Add using mpi ; in project-config.jam file. Then ./b2 —with-mpi will only build the mpi library.
Then, all built libraries can be found in the folder ~/Downloads/boost_1_61_0/stage/lib.
Copy or move them to /usr/local/lib or any other commonly used library path.
Reference: http://www.boost.org/doc/libs/1_61_0/doc/html/mpi/getting_started.html
4. Compile with Boost MPI
LIBRARY DIR = -L/usr/local/lib
INCLUDE = -I/usr/local/include/
LINKER = -lboost_mpi -lboost_serialization
e.g.
mpic++ -std=c++11 -I/usr/local/include/ -c boost_test.cpp -L/usr/local/lib -lboost_mpi -lboost_serialization
Good luck!
I have a C++ shared library being called from my Python program. The C++ lib is compiled with HDF5 which I installed using homebrew on OS X, so it resides in /usr/local/lib. Now the problem is that I also have PyTables installed, which includes an older version of libhdf5, installed somewhere in /Library/Frameworks/EPD64.framework/Versions/Current/...
I can compile and link my library just fine, and otool -L indeed points to /usr/local/lib/libhdf5.dylib. However, when I try to run it from Python, there is a version mismatch error. Somehow the runtime linker is loading the older hdf5 library instead.
One workaround is to build hdf5 as a static library instead, but I'd like to find a neater solution - how can I persuade the runtime linker to use the newer library? I already tried setting DYLD_LIBRARY_PATH but that just broke everything else (Python and MacVim wouldn't start).
Can you provide more info? I have a few alternatives (and questions).
If I understood correctly, you have a library that uses lib_ver_a.dyld and pyTables that uses lib_ver_b.dyld. I.e. the same library but different version.
You could either:
Compile your library to use the same version as pyTables (DYLD_LIB... while you compile) and run your program with pyTables library: DYLD_LIBRARY_PATH=/correct/path/lib python myprog.py
Upgrade your xcode (which version you have? also which osx version?). This upgrades your libraries and pyTables (be careful, newest is not necessary the most stable)
You should also check which python you are calling (a custom one or apple one).
There is also a possibility to define a specific dyld while linking (Do you use gcc or ld for linking? I might miss some options here):
gcc /path/lib1.dyld myLib.c -o myLib.o
This way your library is linked to certain version of the library (caution! I don't remember the exact details, but I can dig them out).
I hope this helps.
br,
Juha