I am trying to install QCL-0.6.4 from this source, but I keep getting errors, when I try it with the make command in the terminal.
I came along this thread about installing QCL on OSX, but when trying to adjust the Makefile I always come across this errors:
extern.cc:84:18: error: variable length array of non-POD element type 'tComplex'
(aka 'complex<double>')
tComplex u[dim][dim];
^
extern.cc:193:9: error: variable length array of non-POD element type 'term'
term t[dim];
^
extern.cc:224:9: error: variable length array of non-POD element type 'term'
term t[dim];
Any help on this would be highly appreciated.
There are a few issues at play here which you need to overcome to get this compiling on OSX. My instructions below assume that you are running on El Capitan (10.11.1 in my instance), but you may get some milage out of them for different versions.
Firstly, Xcode currently uses Apple's LLVM Compiler as the default C++ compiler. However, this doesn't support some of GCC's extensions, such as support for non-POD variable length arrays.
To get around this, I installed and compile with GCC: if you haven't already, install Homebrew, and then install the latest GCC compiler with:
$ brew install gcc
At the time of writing, this will install GCC v5.2.0.
That should fix your initial problem, but you will instantly hit others!
The next issue is that the included libqc.a will need recompiling for x86_64. So you will need to modify the file <base_dir>/qc/Makefile with the following changes:
...
# Add:
CXX = /usr/local/Cellar/gcc/5.2.0/bin/g++-5
CXXFLAGS = $(ARCHOPT) -c -pedantic -Wall $(DEBUG) $(PRGOPT)
...
Then rebuild libqc.a:
$ cd qc; make clean; make
If all goes well, you should have a shiny new libqc.a.
Finally, modify the main Makefile <base_dir>/Makefile with the following changes:
...
# Comment out:
#PLOPT = -DQCL_PLOT
#PLLIB = -L/usr/X11/lib -lplotter
...
# Comment out:
#RLOPT = -DQCL_USE_READLINE
#RLLIB = -lreadline
#RLLIB = -lreadline -lncurses
...
# Comment out:
#CXX = g++
#CPP = $(CC) -E
#CXXFLAGS = -c $(ARCHOPT) $(DEBUG) $(PLOPT) $(RLOPT) $(IRQOPT) $(ENCOPT) -I$(QCDIR) -DDEF_INCLUDE_PATH="\"$(QCLDIR)\""
#LDFLAGS = $(ARCHOPT) -L$(QCDIR) $(DEBUG) $(PLLIB) -lm -lfl -lqc $(RLLIB)
# Add:
CXX = /usr/local/Cellar/gcc/5.2.0/bin/g++-5
CPP = $(CC) -E
CXXFLAGS = -c $(ARCHOPT) $(DEBUG) $(PLOPT) $(RLOPT) $(IRQOPT) $(ENCOPT) -I$(QCDIR) -DDEF_INCLUDE_PATH="\"$(QCLDIR)\""
LDFLAGS = $(ARCHOPT) -L$(QCDIR) $(DEBUG) $(PLLIB) -lm -ll -lqc $(RLLIB) -lc++
...
This should now allow you to build the main application as per the instructions:
$ make clean; make; make install
Related
I have a project that builds with
autoreconf --install
./configure
make
and contains configure.ac and Makefile.am
The project builds 2 libraries and one executable that dynamically links them. One library is cpp, other and the executable are pure C. I want to link one of the libs (cpp one) statically and keep c library to link dynamically. My simplified Makefile.am is
ACLOCAL_AMFLAGS = -I m4
SUBDIRS = include doc po
AM_CPPFLAGS = -Iinclude
AM_CPPFLAGS += -D__STRICT_ANSI__
AM_CPPFLAGS += -DNDEBUG
WARNFLAGS = -Wall
AM_CFLAGS = $(WARNFLAGS) $(OPENMP_CXXFLAGS) -std=c11
AM_CXXFLAGS = $(WARNFLAGS) -std=c++11
localedir = $(datadir)/locale
DEFS = -DLOCALEDIR=\"$(localedir)\" #DEFS#
lib_LTLIBRARIES = libmy.la libmy-settings.la
libmy_la_SOURCES = src/sharedlib.c src/sharedlib.h
libmy_settings_la_SOURCES = src/staticlib.cpp src/staticlib.h
bin_PROGRAMS = myapp
myapp_SOURCES = myapp.c
myapp_LDADD = libmy.la libmy-settings.la
The libtool generates both .a and .so files in ./.libs/ but Libtool prefers .so. In the last make command I see gcc -Wall -std=c11 -g -O2 -o .libs/myapp myapp.o ./.libs/libmy.so ./.libs/libmy-settings.so. If I replace it with gcc -Wall -std=c11 -g -O2 -o .libs/myapp myapp.o ./.libs/libmy.so ./.libs/libmy-settings.a - it works and gives me that I'm trying to achieve. The question is: how to achieve it automatically wit help of Makefile.am?
As I understand, I can't just add myapp_LDFLAGS=-lmy-settings.a bcs it won't replace shared linking argument but add a new one. And I can't remove the libmy-settings.la from lib_LTLIBRARIES or myapp_LDADD bcs it won't generate libmy-settings.a or libmysettings.so in ./.libs/ at all. Any clues?
Since libmy-settings does not need to be a separately installable library, you have two pretty straightfoward alternatives:
Add its sources to myapp_SOURCES, and leave libmy-settings.la completely out of the picture. That the additional sources are located in a different directory and written in a different (autotools-supported) language should not be a problem. This approach may be to your advantage in terms of the Autotools choosing the correct linker driver and options without your intervention, too.
Build libmy-settings.la as a utility library instead of an installable one. This is achieved by marking it noinst:
lib_LTLIBRARIES = libmy.la
noinst_LTLIBRARIES = libmy-settings.la
I have this very simple makefile:
P = hello_world.exe
OBJECTS = main.o
CFLAGS = -g -Wall -O3
LDLIBS =
CC = clang
$(P): $(OBJECTS)
When I run make it will compile main.c but it will not link to hello_world.exe. Shouldn't that be happening automatically?
My environment is cygwin 64bit.
The output of make -p is here: http://pastebin.com/qbr0sRXL
There's no default rule for .exe files that I'm aware of (or can find in that output).
You'll need to write one yourself.
If your output was hello_world and you had a hello_world.c/hello_world.cpp source file and also a main.c/main.cpp file then your makefile as written would work I believe (since the default %: %.o rule would apply and your added prerequisite would be added to the hello_world prerequisite list).
I'm trying to install the latest octave 3.8.1 from source in a cluster running redhat+IBM LSF. I don't have write access to anywhere else except my own home dir, that's why I have to install octave from source. The blas and lapack provided by the cluster does not work so I have to build them by myself. I have now finished compiling both blas and lapack and passed the ./configure, but when I run make, an error is reported as follows:
These are steps I used to build my own BLAS and LAPACK. The source of BLAS is in ~/src/BLAS while the source of LAPACK is in ~/src/lapack-3.5.0 and the source of octave 3.8.1 is in ~/src/octave-3.8.1.
With only two module, 1) pcre/8.33 2) acml/5.3.1/gfortran64, loaded, I compiled BLAS shared library using
gfortran -shared -O2 *.f -o libblas.so -fPIC
and static library using
gfortran -O2 -c *.f -fPIC
ar cr libblas.a *.o
Then I copy the shared library libblas.so to ~/src/octave-3.8.1. The contents of make.inc file in lapack's dir is:
####################################################################
# LAPACK make include file. #
# LAPACK, Version 3.5.0 #
# November 2013 #
####################################################################
#
SHELL = /bin/sh
#
# Modify the FORTRAN and OPTS definitions to refer to the
# compiler and desired compiler options for your machine. NOOPT
# refers to the compiler options desired when NO OPTIMIZATION is
# selected. Define LOADER and LOADOPTS to refer to the loader and
# desired load options for your machine.
#
FORTRAN = gfortran
OPTS = -shared -O2 -fPIC
DRVOPTS = $(OPTS)
NOOPT = -O0 -frecursive
LOADER = gfortran
LOADOPTS =
#
# Timer for the SECOND and DSECND routines
#
# Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME
#TIMER = EXT_ETIME
# For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME_
# TIMER = EXT_ETIME_
# For gfortran compiler: SECOND and DSECND will use a call to the INTERNAL FUNCTION ETIME
TIMER = INT_ETIME
# If your Fortran compiler does not provide etime (like Nag Fortran Compiler, etc...)
# SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME
# TIMER = INT_CPU_TIME
# If neither of this works...you can use the NONE value... In that case, SECOND and DSECND will always return 0
# TIMER = NONE
#
# Configuration LAPACKE: Native C interface to LAPACK
# To generate LAPACKE library: type 'make lapackelib'
# Configuration file: turned off (default)
# Complex types: C99 (default)
# Name pattern: mixed case (default)
# (64-bit) Data model: LP64 (default)
#
# CC is the C compiler, normally invoked with options CFLAGS.
#
CC = gcc
CFLAGS = -O3
#
# The archiver and the flag(s) to use when building archive (library)
# If you system has no ranlib, set RANLIB = echo.
#
ARCH = ar
ARCHFLAGS= cr
RANLIB = ranlib
#
# Location of the extended-precision BLAS (XBLAS) Fortran library
# used for building and testing extended-precision routines. The
# relevant routines will be compiled and XBLAS will be linked only if
# USEXBLAS is defined.
#
# USEXBLAS = Yes
XBLASLIB =
# XBLASLIB = -lxblas
#
# The location of the libraries to which you will link. (The
# machine-specific, optimized BLAS library should be used whenever
# possible.)
#
#BLASLIB = ../../librefblas.a
BLASLIB = ~/src/BLAS/libblas.a
LAPACKLIB = liblapack.a
TMGLIB = libtmglib.a
LAPACKELIB = liblapacke.a
Then I type make to compile LAPACK. After compilation, I copied the output liblapack.a to ~/src/octave-3.8.1.
The ./configure command line is:
./configure --prefix=$HOME/bin/octave --with-blas=./libblas.so --with-lapack=$HOME/src/octave-3.8.1/liblapack.a --disable-readline --enable-64
I can pass the ./configure. Then I type make to try to build octave 3.8.1 and I got the above error.
From the make.inc file it can be seen that I have followed the suggestion of the compiler "recompile with -fPIC" and modified the make.inc accordingly. I also add -shared switch in the OPTS variable. In addition, I have tried using old LAPACK version but not working. I really have no idea why the error still comes out. So I wonder if you could please tell me how to compile the LAPACK library so that it can be correctly used during installation of octave 3.8.1. The following two points may be worth considering. (1) should I compile lapack as a static library or a shared library? (2) should -fPIC switch be applied to lapack compilation or octave's make? If the latter, how to apply -fPIC to make? You don't have to get restricted to the above two points since there may be other reasons for the error. Any advice to solve this problem is welcomed. If you need any other information please tell me. Thank you.
Just compiled the lapack shared lib on my boss's beast... Here's a link which almost did it right.
I made some changes:
(1) Adding -fPIC to
OPTS & NOOPT in make.inc
(2) Change the names in make.inc to .so
BLASLIB = ../../libblas.so
LAPACKLIB = ../liblapack.so
(3) In ./SRC, change the Makefile from
../$(LAPACKLIB): $(ALLOBJ)
$(ARCH) $(ARCHFLAGS) $# $(ALLOBJ)
$(RANLIB) $#
to
../$(LAPACKLIB): $(ALLOBJ)
$(LOADER) $(LOADOPTS) -shared -Wl,-soname,liblapack.so -o $# $(ALLOBJ) ../libblas.so
Cuz lapack is calling blas, if you miss the very last part, your liblapack.so will fail! You need to LINK liblapack.so against libblas.so ( libatlas.so is also OK). You can use "ldd liblapack.so" to check its dependency. If you see libblas.so in there, pretty much you did it right.
(4) In ./BLAS/SRC, change the Makefile from
$(BLASLIB): $(ALLOBJ)
$(ARCH) $(ARCHFLAGS) $# $(ALLOBJ)
$(RANLIB) $#
to
$(BLASLIB): $(ALLOBJ)
$(LOADER) $(LOADOPTS) -z muldefs -shared -Wl,-soname,libblas.so -o $# $(ALLOBJ)
(5) I don't need libtmg.so so that I didn't change it...
Run
make blaslib
Then
make lapacklib
You will have both of them compiled. I check the liblapack.so with building a numpy on it and Python ctypes.cdll loading. All work for me to solve eigenvalues and eigenvectors... So it should be fine...
(6) YOU MAY NEED TO SET UP LD_LIBRARY_PATH to where you keep your library files.
google it... If not set by admin, then
export LD_LIBRARY_PATH=path-to-lib
If already set, then
export LD_LIBRARY_PATH=path-to-lib:$LD_LIBRARY_PATH
to overwrite your default libs.
So that you won't have ld linking errors. Good luck!!
In lapack-3.7.0, there are redundant lines in the SRC/Makefile. Simply deleting them will solve your error.
I would suggest using OpenBLAS.
> git clone https://github.com/xianyi/OpenBLAS.git
> make
> make make --PREFIX=INSTALL_DIR install
move the librabries from OpenBLAS to /usr/lib64
> cp /path/to/OpenBLAS/lib/* /usr/lib64/
then go to the octave installation path and run
> "your specific flags" ./configure "your specific arguments" --with-blas="-lopenblas"
Hadoop n00b here, just started playing around with Hadoop Pipes. I'm getting linker errors while compiling a simple WordCount example using hadoop-0.20.203 (current most recent version) that did not appear for the same code in hadoop-0.20.2
Linker errors of the form: undefined reference to `EVP_sha1' in HadoopPipes.cc.
EVP_sha1 (and all of the undefined references I get) are part of the openssl library which HadoopPipes.cc from hadoop-0.20.203 uses, but hadoop-0.20.2 does not.
I've tried adjusting my makefile to link to the ssl libraries, but I'm still out of luck. Any ideas would be greatly appreciated. Thanks!
PS, here is my current makefile:
CC = g++
HADOOP_INSTALL = /usr/local/hadoop-0.20.203.0
SSL_INSTALL = /usr/local/ssl
PLATFORM = Linux-amd64-64
CPPFLAGS = -m64 -I$(HADOOP_INSTALL)/c++/$(PLATFORM)/include -I$(SSL_INSTALL)/include
WordCount: WordCount.cc
$(CC) $(CPPFLAGS) $< -Wall -Wextra -L$(SSL_INSTALL)/lib -lssl -lcrypto -L$(HADOOP_INSTALL)/c++/$(PLATFORM)/lib -lhadooppipes -lhadooputils -lpthread -g -O2 -o $#
The actual program I'm using can be found at http://cs.smith.edu/dftwiki/index.php/Hadoop_Tutorial_2.2_--_Running_C%2B%2B_Programs_on_Hadoop
Had same problem here: answer is to add -lcrypto to the compile command line:
http://grokbase.com/p/hadoop.apache.org/common-user/2011/06/re-linker-errors-with-hadoop-pipes/09zqdt5grdudu7no7q6k3gfcynpy
Here is a patch to fix the build process:
diff --git src/examples/pipes/Makefile.in src/examples/pipes/Makefile.in
index 17efa2a..1d8af8e 100644
--- src/examples/pipes/Makefile.in
+++ src/examples/pipes/Makefile.in
## -233,7 +233,7 ## AM_CXXFLAGS = -Wall -I$(HADOOP_UTILS_PREFIX)/include \
-I$(HADOOP_PIPES_PREFIX)/include
LDADD = -L$(HADOOP_UTILS_PREFIX)/lib -L$(HADOOP_PIPES_PREFIX)/lib \
- -lhadooppipes -lhadooputils
+ -lhadooppipes -lhadooputils -lcrypto
# Define the sources for each program
You just need to make some changes to your Makefile. The libraries that natively accompany hadoop seem not to do it. You'll need to "re-make" them and change your linked path.
A comprehensive answer to this can be found at http://goo.gl/y5iGZF.
Hello I would like to ask you, If someone knows how can I add a directory for the header files in the Makefile to avoid the error *.h not found, I have tried this option but does not work:
INC_PATH := -I /directory/to/add
At least for GNU make, try the implicit variable CFLAGS, as in:
CFLAGS=-I/directory/to/add
Although the goal is ultimately to affect the value of CFLAGS (as suggested by #unwind), it is often not a good idea to simply set the value of CFLAGS as it is often built out of many pieces. You have to understand the structure of the makefile, and the set of macros used.
[Added:
Eduardo asked: Can you post macros to do the same?
Yes, but whether they are helpful depends on how your makefiles are structured. Here's a moderately complex example from one of my makefiles.
CC = gcc -g
XFLAGS = -Wall -Wshadow -Wstrict-prototypes -Wmissing-prototypes \
-DDEBUG -Wredundant-decls
#CC = cc -g
#XFLAGS =
UFLAGS = # Always overrideable on the command line
DEPEND.mk = sqlcmd-depend.mk
INSTALL.mk = sqlcmd-install.mk
ESQLC_VERSION = `esqlcver`
OFLAGS = # -DDEBUG_MALLOC -g
OFLAGS = -g -DDEBUG -O4
PFLAGS = -DHAVE_CONFIG_H
OFILES.o = # rfnmanip.o # malloc.o # strdup.o # memmove.o
VERSION = -DESQLC_VERSION=${ESQLC_VERSION}
#INC1 = <defined in sqlcmd-depend.mk>
#INC2 = <defined in sqlcmd-depend.mk>
INC3 = /usr/gnu/include
INC4 = ${INFORMIXDIR}/incl/esql
INC5 = . #${INFORMIXDIR}/incl
INCDIRS = -I${INC3} -I${INC1} -I${INC2} -I${INC4} -I${INC5}
LIBSQLCMD = libsqlcmd.a
STRIP = #-s
LIBC = #-lc_s
LIBMALLOC = #-lefence
LIBRDLN = -lreadline
LIBCURSES = -lcurses
LIBPOSIX4 = -lposix4
LIBG = #-lg
LIBDIR1 = ${HOME}/lib
LIBDIR2 = /usr/gnu/lib
LIBJL1 = ${LIBDIR1}/libjl.a
LIBJL2 = ${LIBDIR1}/libjlss-${ESQLC_VERSION}.a
LIBTOOLS = ${LIBJL2} ${LIBJL1}
LDFLAGS = ${LIBSQLCMD} ${LIBTOOLS} -L${LIBDIR2} ${LIBG} ${LIBMALLOC} \
${LIBPOSIX4} ${LIBC} ${STRIP}
CFLAGS = ${VERSION} ${INCDIRS} ${OFLAGS} ${XFLAGS} ${PFLAGS} ${UFLAGS}
This a makefile for a program of mine called sqlcmd (a name chosen a decade and more before Microsoft created a command of the same name). I assume that the make program has a rule for compiling C code to object like:
${CC} ${CFLAGS} -c $*.c
and that the rule for linking a program from a set of object files listed in the macro OBJECTS looks like:
${CC} ${CFLAGS} -o $# ${OBJECTS} ${LDFLAGS}
As you can see, there are separately settable macros for the ESQLC_VERSION (the version of Informix ESQL/C in use, derived by default by runing a script esqlcver), then the include directories via INC1 to INC5 and INCFLAGS (there can be quite a lot of these, depending on platform), and optimizer flags (OFLAGS), extra flags (CFLAGS), user-defined flags (UFLAGS - an idiom I use in most of my makefiles; it allows the user to set UFLAGS on the make command line and add an extra flag to the build), and a bunch of library-related macros. This is what it takes for my development makefile to be tunable with minimal fuss to my development platform, which can be Linux, Solaris or MacOS X. For consumers of the program, there is a configure script generated by autoconf, so they don't have to worry about getting those bits right. However, that has a strong genetic resemblance to this code, including the UFLAGS option.
Note that many systems for makefile building have a mechanism for setting CFLAGS faintly similar to this - and simply assigning to CFLAGS undoes the good work done by the system. But you have to understand your makefile to be able to modify it sanely.
]