I am trying to compile my code using mpi on my macbook but I get the following error:
"ld: library not found for -lblacsF77init". I don't understand where I can find this library and how to create a correct path.
This is the makefile: # serial Fortran compiler program
F90 = gfortran -I/usr/local/include
# parallel Fortran compiler program
MPIF90 = /usr/local/bin/mpif90.
# Compiler flags
F90FLAGS =
CFLAGS = -x f95-cpp-input.
# LDFLAGS are the linker flags
LDFLAGS = -L/usr/local/lib
F77LIBS =.
MATLIB = -framework Accelerate
hsl = /usr/local/opt/scalapack/
hb = /usr/local/opt/openblas/
hompi = /usr/local/lib/openmpi/
MPIMATLIB = -L$(hb) -L$(hsl) -lscalapack -L$(hsl) -lblacsF77init -
lblacs -lblacsF77init -L$(hompi) -Wl,-framework,vecLib
Thank you very much for any help you may provide.
If you are on a macbook running OSX, you don't need to build scalapack:
brew install scalapack gcc
Related
I have a project that I am working on converting over to autotools.
Here are the relevant files
configure.ac
AC_INIT([opengl-es-demo], [1])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_LANG(C++)
AC_PROG_CXX
PKG_CHECK_MODULES(LIBPNG, libpng >= 1.6.34)
PKG_CHECK_MODULES(FREETYPE2, freetype2 >= 21.0.15)
PKG_CHECK_MODULES(EGL, egl > 0)
PKG_CHECK_MODULES(GLES2, glesv2 > 0)
PKG_CHECK_MODULES(PTHREAD, pthread-stubs > 0)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Makefile.am
bin_PROGRAMS = main
main_SOURCES = main.cpp eglManager.cpp shaderManager.cpp imageUtils.cpp freetypeUtils.cpp texture.cpp shader.cpp camera.cpp
main_CPPFLAGS = $(FREETYPE2_CFLAGS) $(LIBPNG_CFLAGS) $(EGL_CFLAGS) $(GLES2_CFLAGS) $(PTHREAD_CFLAGS)
main_LDFLAGS = $(FREETYPE2_LIBS) $(LIBPNG_LIBS) $(EGL_LIBS) $(GLES2_LIBS) $(PTHREAD_LIBS)
The linker calls this step...
g++ -g -O2 -lfreetype -lpng16 -lz -lEGL -lGLESv2 -o main main-main.o main-eglManager.o main-shaderManager.o main-imageUtils.o main-freetypeUtils.o main-texture.o main-shader.o main-camera.o
...and then fails with a bunch of undefined reference errors to functions found in OpenGL(-GLESv2), png(-lpng16), and freetype(-lfreetype) libraries.
It compiled fine when I wasn't using autotools (only a makefile) so I know the problem is with my autotools usage.
Where did I mess up the configuration?
Changing main_LDFLAGS to main_LDADD solved the problem.
Correcting the GCC command line ordering using Automake
I'm been attempting to compile an open-source C++ library (QuantLib-1.7) on my mac for several days but I seem to be encountering some kind of C++11 compatibility issue.
When I run make && sudo make install from the terminal the compilation seems to work except for a bunch of errors of the form
Making all in BermudanSwaption
g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. -I/opt/local/include -g -O2 -MT BermudanSwaption.o -MD -MP -MF .deps/BermudanSwaption.Tpo -c -o BermudanSwaption.o BermudanSwaption.cpp
In file included from BermudanSwaption.cpp:22:
In file included from ../../ql/quantlib.hpp:43:
In file included from ../../ql/experimental/all.hpp:25:
In file included from ../../ql/experimental/volatility/all.hpp:21:
In file included from ../../ql/experimental/volatility/zabr.hpp:31:
In file included from ../../ql/math/statistics/incrementalstatistics.hpp:35:
In file included from /opt/local/include/boost/accumulators/statistics/stats.hpp:14:
In file included from /opt/local/include/boost/accumulators/statistics_fwd.hpp:12:
/opt/local/include/boost/mpl/print.hpp:50:19: warning: in-class initialization
of non-static data member is a C++11 extension [-Wc++11-extensions]
const int m_x = 1 / (sizeof(T) - sizeof(T));
^
1 warning generated.
I'm guessing this has something to do with g++ not being correctly configured for C++11. I'm familiar with the fact that C++11 can be invoked by compiling with g++ -std=c++11. However, despite a lot of googling I can't find a way to modify the makefile such that -std=c++11 is called when I run make && sudo make install.
Any help would be greatly appreciated.
Here is the section of the makefile which I believe is relevant:
BOOST_INCLUDE = -I/opt/local/include
BOOST_LIB = -L/opt/local/lib
BOOST_THREAD_LIB =
BOOST_UNIT_TEST_DEFINE = -DQL_WORKING_BOOST_STREAMS
BOOST_UNIT_TEST_LIB = boost_unit_test_framework-mt
BOOST_UNIT_TEST_MAIN_CXXFLAGS = -DBOOST_TEST_DYN_LINK
CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS = -g -O2
CPP = gcc -E
CPPFLAGS = -I/opt/local/include
CXX = g++
CXXCPP = g++ -E
CXXDEPMODE = depmode=gcc3
CXXFLAGS = -g -O2
Here is the output from running "g++ -v":
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Makefile.am: https://www.dropbox.com/s/v5j7qohwfup81od/Makefile.am?dl=0
Makefile.in: https://www.dropbox.com/s/t92hft9ea2ar1zw/Makefile.in?dl=0
QuantLib-1.7 directory: https://www.dropbox.com/sh/ulj0y68m8x35zg8/AAA-w7L2_YWIP8_KnwURErzYa?dl=0
Full error log: https://www.dropbox.com/s/g09lcnma8skipv7/errors.txt?dl=0
Add something like
CXXFLAGS += -std=c++11
to your Makefile. This will work regardless of the Darwin-specific munging of the g++ executable---it's really clang++.
References:
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options
https://gcc.gnu.org/projects/cxx0x.html
http://clang.llvm.org/cxx_status.html
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
As you already have, and are familiar with homebrew, my suggestion would be to use that to install and manage quantlib like this:
brew install quantlib
That will then build and put all the files in /usr/local/Cellar/quantlib under some version number that is not of importance. The important thing is the the tools are then linked into /usr/local/bin so all you need to do is make sure that /usr/local/bin is in your PATH.
That gives you access to the tool quantlib-config which is always linked to the latest version and it knows which version that is. So, if you run:
quantlib-config --cflags
it will tell you what the correct path is for your includes like this:
-I/usr/local/Cellar/quantlib/1.6.1/include
Likewise, if you run:
quantlib-config --libs
it will tell you the correct linking directories and libraries for your latest version.
In short, all you need to do to compile is:
g++ $(quantlib-config --cflags --libs)
and it will always pull in the version you are using.
Note that if you use a Makefile, you will need to double the dollar signs.
This is how I eventually managed to compile the Quantlib library for future reference. It is probably not the most efficient/elegant method but it appears to work.
I followed the steps given in http://quantlib.org/install/macosx.shtml and found that running make && sudo make install led to the error reported in the OP.
Create a new static library C++ project in Eclipse called 'Quantlib'
Copy the ql directory located in the .tar file to the Quantlib Eclipse workspace
Right-click Quantlib > Properties > C/C++ Build > Settings > Cross G++ Compiler: Change the Language standard to ISO C++ 11 (-std=c++0x)
Right-click Quantlib > C/C++ General > Paths and Symbols: Add the following include directories for GNU C++
opt/local/include
/Quantlib (check "Is a workspace directory")
/opt/local/include/boost.
Build the Quantlib project (around 34 min on MacBook Air 1.8 GHz Intel Core i7)
Create a new C++ executable project (e.g. BermudanSwaption) and copy the BermudanSwaption.cpp into the BermudanSwaption Eclipse workspace
Repeat steps 4. and 5. for the BermudanSwaption Eclipse project
Right-click BermudanSwaption > Properties > C/C++ General > Paths and Symbols > References: check Quantlib (the Library Paths tab should now contain the entry '/Quantlib/Debug')
Build and run the BermudanSwaption executable project
QuantLib-1.7
OSX Yosemite 10.10.5
Eclipse C/C++ Development Tools Version: 8.8.0.201509131935
Xcode Version 7.1 (7B91b)
xcode-select version 2339.
I am compiling a third-part software, with mpif90, that in my case is the mpi version of gcc. The package comes with a makefile. After compiling the object files, the makefile creates the archive with ar, but this fails because there are not input object files. In effect I tried to compile by hand the object files (.o) with
mpif90 -lmkl_gf -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -openmp -O3 -DMPI -c a.f90
and the a.o is not created, a .mod file is created instead. I don't have much experience with fortran, and I am a bit puzzled, because the -c flag should create an object, shouldn' it?
I have verified that gfortran does create the object file if I remove the flag openmp
Notes:
mpif90 -v
gcc version 4.4.3
OS : Ubuntu 10.04.4 LTS
I changed the flag openmp to fopenmp
http://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
In case anyone comes across this question in the future ... the flags used by the OP are specific to the intel fortran compiler while it seems the mpif90 wrapper is using the gfortran compiler. The proper flag to use OpenMP with gfortran is -fopenmp and the library is -lgomp. It is possible to use the intel library with a different vendors compiler, but its easiest to stick with one vendor.
I recently downloaded the graclus software. While trying to install it I had to be complete the makefile.in with some options.I figured out other options but I couldn't find what do we write for the LDOPTIONS.
Can anybody help me out in figuring what do I fill in the options used by the compiler?
Help will be truly appreciated.
//Here is the makefile.in
# Which compiler to use
CC = g++
# What optimization level to use
OPTFLAGS = -O2 -fPIC
# What options to be used by the compiler
COPTIONS = -DNUMBITS=32
# What options to be used by the loader
LDOPTIONS =
# What archiving to use
AR = ar rv
# What to use for indexing the archive
RANLIB = ranlib
ARCH = P4SSE2
LAPACK = -llapack_$(ARCH)
ARPACK = -lcarpack_$(ARCH)
ATLAS = -latlas_$(ARCH)
CBLAS = -lcblaswr -lcblas -lblas -lmyf2c
GSL = -lgslcblas -lgsl
SPARSE = -lsparse
UTIL = -lmyutil
Since the Makefile you provided is just an excerpt and you've not mentioned what package or library you're compiling it with, I'm just making a wild-guess here.
LDOPTIONS could serve a similar puprose as the commonly used variable LDFLAGS which provides a way to specify extra flags to the linker. It depends on the linker you use. If you're using gcc, then you can run man ld to see the list of linker options.
I'm trying to generate a python wrapper for a C++ library that I am putting together. I have just come across SWIG and am trying to use this in conjunction with distutils. I'm modifying someone elses code, so odd errors were to be expected but this one is just confusing.
I've managed to generate a c++ wrapper file with SWIG and am now attempting to run a modified version of setup.py in order to install the wrapper (which itself may or may not work, but I'll cross that bridge when it comes to it.) When doing this compiler errors pop up about inability to include header files. Specifically - string, ostream, sstream, map and vector. All of which are standard libraries, included as "include ".
The code itself compiles, but in trying to create a wrapper this way it does not.
I'm not entirely sure what information is relevant to this but this is how the extension is made:
## Extension definition
import os
wrapsrc = './project_rewrite_wrap.c'
incdir_src = os.path.abspath('../include/project')
incdir_build = os.path.abspath('../include/project')
libdir = os.path.abspath('../lib')
ext = Extension('_project_rewrite',
[wrapsrc],
include_dirs=[incdir_src, incdir_build],
library_dirs=[libdir, os.path.join(libdir,'.libs')],
libraries=['ProjectMain'])
The gcc command that is run is:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/home/ben/Project/rewrite/include/Project -I/home/ben/Project/rewrite/include/Project -I/usr/include/python2.6 -c ./project_rewrite_wrap.c -o build/temp.linux-i686-2.6/./project_rewrite_wrap.o
Which results in errors such as:
./project_rewrite_wrap.c:2696:18: error: string: No such file or directory
Any thoughts would be greatly appreciated, thanks.
You are compiling C code - the headers you mention are part of C++, not C. To compile as C++ code, use the g++ driver instead of gcc, and give the source files a .cpp extension instead of .c.