Problem summary
I am trying to install an open-source parallel finite-element code called TACS and available at this github repository. To comply with the indicated prerequisites, I followed the instructions at this github repository, which allowed me to install SuiteSparse and METIS on Windows with precompiled BLAS/LAPACK DLLs. For the MPI, I installed both the Intel MPI Library and Open MPI through Cygwin. The final step should be to compile running make, however this command is not directly available in Windows 10. As a consequence, I explored the options suggested in this question, unfortunately without success. I feel at a dead end, any help will be appreciated.
What I've tried
Please have a look below at my attempts. I am mainly a Windows user and I don't know much of compiling programs using Makefile. My current understanding is that the Makefile that I am trying to compile is written for Linux and whatever GNU compiler for Windows I use will not work because of the different syntax needed. Please correct me if I am wrong. What I can't understand is why I get errors also when I try to compile with Ubuntu Bash for Windows 10 (last attempt of the list below).
Visual Studio nmake
Running the Developer Command Prompt for VS 2019 as administrator, I typed nmake -f Makefile in TACS base directory and I got Makefile.in(28) : fatal error U1001: syntax error : illegal character '{' in macro Stop.
Chocolatey make
Running Windows Command Prompt as administrator with C:\ProgramData\chocolatey\bin at the top of PATH environment variable, I typed make in TACS base directory and I got
"" was unexpected at this time.
make: *** [Makefile:23: default] Error 255
Cygwin make
Running Windows Command Prompt as administrator with C:\cygwin64\bin at the top of PATH environment variables, I typed make in TACS base directory and I got three types of error:
error: expected ',' or '...' before numeric constant
error: cannot convert 'int*' to 'idx_t*' {aka 'long int*'}
error: no matching function for call to 'TACSSchurMat::getBCSRMat(BCSRMat**, NULL, NULL, NULL)'
I tried to change some variable names in the affected scripts (like N_ in place of _N) and I got rid of the first and the third type of error, but not of the second one.
GnuWin make
Running Windows Command Prompt as administrator with C:\Program Files (x86)\GnuWin32\bin at the top of PATH environment variables, I typed make in TACS base directory and I got
"" was unexpected at this time.
make: *** [Makefile:23: default] Error 255
MinGW mingw32-make
Running Windows Command Prompt as administrator with C:\MinGW\bin at the top of PATH environment variables, I typed mingw32-make in TACS base directory and I got
"" was unexpected at this time.
Makefile:23: recipe for target 'default' failed
mingw32-make: *** [default] Error 255
MSYS MinGW 64-bit make
Running Windows Command Prompt as administrator with C:\msys64\usr\bin at the top of PATH environment variables, I typed make in TACS base directory and I got
make[1]: mpicxx: No such file or directory
make[1]: *** [../TACS_Common.mk:28: C:/Users/qa21944/git/tacs/src/TACSAssembler.o] Error 127
make[1]: *** Waiting for unfinished jobs....
make[1]: mpicxx: No such file or directory
make[1]: *** [../TACS_Common.mk:28: C:/Users/qa21944/git/tacs/src/TACSCreator.o] Error 127
make[1]: Leaving directory '/c/Users/qa21944/git/tacs/src'
make: *** [Makefile:23: default] Error 1
This is quite difficult for me to understand, as the mpicxx file is C:\Program Files (x86)\Intel\oneAPI\mpi\latest\bin, which in turn is in the PATH environment variable. When I tried to add C:\cygwin64\bin to PATH (below C:\msys64\usr\bin) and to rerun make, I got
0 [main] opal_wrapper (14432) C:\cygwin64\bin\opal_wrapper.exe: *** fatal error - cygheap base mismatch detected - 0x180352408/0x180357408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
I tried to follow these instructions and then rebooted my computer, but nothing changed.
Ubuntu Bash for Windows 10 make
This attempt was inspired by this answer. I downloaded Ubuntu from Microsoft Store and installed make. From the Ubuntu Bash I typed make in TACS base directory and I got
make[1]: Entering directory '/mnt/c/Users/qa21944/git/tacs/src'
Makefile:26: *** target pattern contains no '%'. Stop.
make[1]: Leaving directory '/mnt/c/Users/qa21944/git/tacs/src'
make: *** [Makefile:23: default] Error 1
I do not understand why I should get this error. I also made sure that all lines started with a tab rather than white spaces, but nothing changed.
Codes
Below you can find the Makefile.in and Makefile that I am using.
Makefile.in
# Do not modify this file. Copy this file to Makefile.in and then modify it.
# In order to get TACS to compile, you'll need to fill in the
# following path information. Some of the items below are required
# only if you're going to use the python interface.
# the full path to the root TACS directory
TACS_DIR = C:/Users/qa21944/git/tacs
CXX = mpicxx
RM = rm -f
PYTHON = python
PYTHON_CONFIG = python-config
# Set up for parallel make
MAKE = make -j 8
# Set the ar flags
AR_FLAGS = rcs
# Flags for debugging and regular compilation versions
EXTRA_DEBUG_CC_FLAGS = -fPIC -g
EXTRA_CC_FLAGS = -fPIC -O3
# Use this if you have problems with mpich
# TACS_DEF = -DMPICH_IGNORE_CXX_SEEK
# Defines whether to use static or dynamic linking
# TACS_LD_CMD=${TACS_DIR}/lib/libtacs.a
TACS_LD_CMD=-L${TACS_DIR}/lib/ -Wl,-rpath,${TACS_DIR}/lib -ltacs
# For linux systems, use the following settings:
SO_EXT=so
SO_LINK_FLAGS=-fPIC -shared
# For MAC OS X, use the following settings:
# SO_EXT=so
# SO_LINK_FLAGS=-fPIC -dynamiclib
# This uses the default installation of LAPACK.
# Use an optimized version of LAPACK if available.
# You may also have to include -lblas as well.
LAPACK_LIBS = -LC:/SP_ROOT/lapack_windows/x64 -llapack -lpthread -lblas
# For MAC OSX use the accelerate framework
# LAPACK_LIBS=-framework accelerate
# METIS is handy for partitioning graphs, but can be problematic for
# compilation. If you compile METIS using a C++ compiler you must add
# -DTACS_CPLUSPLUS_METIS to the TACS_DEF arguments below. If you
# compile METIS using a C compiler, there should be no issues.
METIS_INCLUDE = -IC:/SP_ROOT/build/install/include
METIS_LIB = -LC:/SP_ROOT/build/install/lib -lmetis
# AMD is a set of routines for ordering matrices. It is not required by default.
AMD_INCLUDE = -IC:/SP_ROOT/build/install/include/suitesparse
AMD_LIBS = -LC:/SP_ROOT/build/install/lib -llibamd
Makefile
# ============================================
#
# Make file for TACS_DIR/
#
# ============================================
include Makefile.in
include TACS_Common.mk
TACS_SUBDIRS = src \
src/bpmat \
src/elements \
src/elements/dynamics \
src/elements/basis \
src/elements/shell \
src/constitutive \
src/functions \
src/io
TACS_OBJS := $(addsuffix /*.o, ${TACS_SUBDIRS})
default:
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "Building Complex TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) TACS_DIR=${TACS_DIR} TACS_DEF="${TACS_DEF} -DTACS_USE_COMPLEX") || exit 1; \
done \
else \
echo "Building Real TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) TACS_DIR=${TACS_DIR}) || exit 1; \
done \
fi
${CXX} ${SO_LINK_FLAGS} ${TACS_OBJS} ${TACS_EXTERN_LIBS} -o ${TACS_DIR}/lib/libtacs.${SO_EXT}
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "ctypedef complex TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_CDOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = complex" >> tacs/TacsDefs.pxi; \
else \
echo "ctypedef double TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_DOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = np.double" >> tacs/TacsDefs.pxi; \
fi
debug:
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "Building Complex TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) debug TACS_DIR=${TACS_DIR} TACS_DEF="${TACS_DEF} -DTACS_USE_COMPLEX") || exit 1; \
done \
else \
echo "Building Real TACS"; \
for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; (cd $$subdir && $(MAKE) debug TACS_DIR=${TACS_DIR}) || exit 1; \
done \
fi
${CXX} ${SO_LINK_FLAGS} ${TACS_OBJS} ${TACS_EXTERN_LIBS} -o ${TACS_DIR}/lib/libtacs.${SO_EXT}
#if [ "${TACS_IS_COMPLEX}" = "true" ]; then \
echo "ctypedef complex TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_CDOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = complex" >> tacs/TacsDefs.pxi; \
else \
echo "ctypedef double TacsScalar" > tacs/TacsTypedefs.pxi; \
echo "TACS_NPY_SCALAR = np.NPY_DOUBLE" > tacs/TacsDefs.pxi; \
echo "dtype = np.double" >> tacs/TacsDefs.pxi; \
fi
interface:
${PYTHON} setup.py build_ext --inplace
complex_interface:
${PYTHON} setup.py build_ext --inplace --define TACS_USE_COMPLEX
complex: TACS_IS_COMPLEX=true
complex: default
complex_debug: TACS_IS_COMPLEX=true
complex_debug: debug
clean:
${RM} lib/libtacs.a lib/libtacs.so
${RM} tacs/*.so tacs/*.cpp
#for subdir in $(TACS_SUBDIRS) ; do \
echo "making $# in $$subdir"; \
echo; \
(cd $$subdir && $(MAKE) $# TACS_DIR=${TACS_DIR}) || exit 1; \
done
Edit: I am adding a snippet of TACS_Common.mk as requested in the comments.
TACS_Common.mk
TACS_LIB = ${TACS_DIR}/lib/libtacs.a
TACS_INCLUDE = -I${TACS_DIR}/src \
-I${TACS_DIR}/src/bpmat \
-I${TACS_DIR}/src/elements \
-I${TACS_DIR}/src/elements/dynamics \
-I${TACS_DIR}/src/elements/basis \
-I${TACS_DIR}/src/elements/shell \
-I${TACS_DIR}/src/constitutive \
-I${TACS_DIR}/src/functions \
-I${TACS_DIR}/src/io
# Set the command line flags to use for compilation
TACS_OPT_CC_FLAGS = ${TACS_DEF} ${EXTRA_CC_FLAGS} ${METIS_INCLUDE} ${AMD_INCLUDE} ${TACS_INCLUDE}
TACS_DEBUG_CC_FLAGS = ${TACS_DEF} ${EXTRA_DEBUG_CC_FLAGS} ${METIS_INCLUDE} ${AMD_INCLUDE} ${TACS_INCLUDE}
# By default, use the optimized flags
TACS_CC_FLAGS = ${TACS_OPT_CC_FLAGS}
# Set the linking flags to use
TACS_EXTERN_LIBS = ${AMD_LIBS} ${METIS_LIB} ${LAPACK_LIBS}
TACS_LD_FLAGS = ${EXTRA_LD_FLAGS} ${TACS_LD_CMD} ${TACS_EXTERN_LIBS}
# This is the one rule that is used to compile all the
# source code in TACS
%.o: %.cpp
${CXX} ${TACS_CC_FLAGS} -c $< -o $*.o
#echo
#echo " --- Compiled $*.cpp successfully ---"
#echo
I can't answer but maybe I can orient you.
First nmake is not make. It will not work with any makefile not written specifically as an nmake makefile. And it's only available on Windows. So, best to just forget it exists.
Second, it's important to understand how make works: rules in makefiles are a combination of targets/prerequisites, and a recipe. The recipe is not in "makefile" syntax, it's a shell script (batch file). So make works in tandem with the shell, to run commands. Which shell? On POSIX systems like GNU/Linux and MacOS it's very simple: a POSIX shell; by default /bin/sh.
On Windows systems it's much less simple: there are a lot of options. It could be cmd.exe. It could be PowerShell. It could be a POSIX shell, that was installed by the user. Which one is chosen by default, depends on how your version of make was compiled. That's why you see different behaviors for different "ports" of make to Windows.
So, if you look at the makefiles you are trying to use you can see they are unquestionably written specifically for a POSIX system and expect a POSIX shell and a POSIX environment. Any attempt to use a version of make that invokes cmd.exe as its default shell will fail immediately with syntax errors ("" was unexpected at this time.).
OK, so you find a version of make that invokes a POSIX shell, and you don't get that error anymore.
But then you have to contend with another difference: directory separators. In Windows they use backslash. In POSIX systems, they use forward slash and backslash is an escape character (so it's not just passed through the shell untouched). If you are going to use paths in a POSIX shell, you need to make sure your paths use forward slashes else the shell will remove them as escape characters. Luckily, most Windows programs accept forward slashes as well as backslashes as directory separators (but not all: for example cmd.exe built-in tools do not).
Then you have to contend with the Windows abomination known as drive letters. This is highly problematic for make because to make, the : character is special in various places. So when make sees a line like C:/foo:C:/bar its parser will get confused, and you get errors. Some versions of make compiled for Windows enable a heuristic which tries to see if a path looks like a drive letter or not. Some just assume POSIX-style paths. They can also be a problem for the POSIX shell: many POSIX environments on Windows map drive letters to standard POSIX paths, so C:\foo is written as /c/foo or /mnt/c/foo or something else. If you are adding paths to your makefile you need to figure out what the right mapping, if any, is and use that.
That's not even to start discussing the other differences between POSIX and Windows... there are so many.
From what you've shown above, this project was not written with any sort of portability to Windows in mind. Given the complexity of this, that's not surprising: it takes a huge amount of work. So you have these options that I can see:
Port it yourself to be Windows-compatible
Try to get it working inside cygwin (cygwin is intended to be a POSIX-style environment that runs on Windows)
Try to get it working in WSL
Install a virtual machine using VMWare, VirtualBox, etc. running a Linux distribution and build and run it there
Unfortunately I don't know much about the pros and cons of these approaches so I can't advise you as to the best course.
The route I chose, long long ago, was to get rid of Windows entirely and just use GNU/Linux. But of course that won't be possible for everyone :).
You need a real answer: you can't compile using the Windows Command Prompt.
Get yourself MSYS2 -- which will also install MinGW-w64 -- and follow the setup instructions. Then launch the MSYS shell to get a unix-y terminal prompt (zsh, IIRC), and change directory to the head of the project folder.
To access the Windows filesystem the root directory will be either /c or /mnt/c (sorry, on my mobile ATM, I can improve this in a day or two). For example,
C:\Users\qa21944\git\tacs
becomes
/c/Users/qa21944/git/tacs
From there the GNU/Windows make command should work:
mingw32-make
There is also this post to use more modern *nix environments under Windows:
How to install and use "make" in Windows?
Thanks may be overkill for what you need, though.
When I finish traveling and can sit down to look at this properly I can improve this answer's details, but getting a Linux shell terminal is what you need.
I have inherited a build system that uses autoconf and automake to build. I am not at all familiar with how this works except on a high level.
The build system itself works fine. However a lot of warnings are generated from system headers. In my case wxWidgets. The cause of this is that the include dir of wxWidgets is passed as -I instead of -isystem. I have searched online but I can't find how I can change this.
The following code is in the configure.ac file:
AM_OPTIONS_WXCONFIG
AM_PATH_WXCONFIG(3.0.2, wxWin=1, , ,[--debug=yes])
if test "$wxWin" != 1; then
AC_MSG_ERROR([
wxWidgets must be installed on your system
but no wx-config script could be found.
Please check that wx-config is in path, the directory
where wxWidgets libraries are installed as returned by
'wx-config --libs' is in the linker path (LD_LIBRARY_PATH
or equivalent variable) and wxWidgets version is 2.9.4 or
above.
])
fi
if test "$wxWin" != 0; then
AC_DEFINE(HAVE_WXWIDGETS,1,[define if the wxWidgets 3.0.2. or higher is available])
fi
Then there is a Makefile.am which does the following:
bin_PROGRAMS = project
project_SOURCES = {sources here}
project_CPPFLAGS = $(AM_CPPFLAGS) $(PROJECT_CPPFLAGS) $(WX_CPPFLAGS)
project_CFLAGS = $(AM_CFLAGS) $(PROJECT_CFLAGS) $(WX_CFLAGS)
project_CXXFLAGS = $(AM_CXXFLAGS) $(PROJECT_CXXFLAGS) $(WX_CXXFLAGS)
project_LDFLAGS = $(AM_LDFLAGS)
project_LDADD = $(AM_LIBADD) $(WX_LIBS)
There doesn't seem an option that I can specify it as a system header in some way.
Do anyone of you know how I can tackle this?
The problem has nothing to do with autoconf. It's the wx-config tool that is the culprit. That tool is used to obtain the include directories. For instance invoking wx-config --cxxflag will result in this:
-I/usr/lib/wx/include/gtk2-unicode-3.1 -I/usr/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread
Which is passed to the compiler. There are a couple of ways of solving this. Either manually replace it in the output or patch wx-config.
I feel like I must be doing something fundamentally wrong. I created a recipe based on a cmake project. Compiling the project using the toolchain yocto created is as simple as running cmake then make but it fails to compile using a recipe:
SUMMARY = "Opendnp3 is the de facto reference implementation of IEEE-1815 (DNP3)"
DESCRIPTION = "Opendnp3 is a portable, scalable, and rigorously tested implementation of the DNP3 (www.dnp.org) protocol stack written in C++11. The library is designed for high-performance applications like many concurrent TCP sessions or huge device simulations. It also embeds very nicely on Linux."
HOMEPAGE = "https://www.automatak.com/opendnp3"
SECTION = "libs"
DEPENDS = "asio"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://NOTICE;md5=9788d3abe6c9401d72fdb3717de33e6a"
SRCREV = "e00ff31b837821064e5208c15866a9d46f8777b1"
SRC_URI = "git://github.com/automatak/dnp3;branch=2.0.x"
S = "${WORKDIR}/git"
inherit cmake
EXTRA_OECMAKE += ""
Problem is I think that the CXXFLAGS used for g++ don't appear to be consistent with the CXXFLAGS defined by the toolchain's environment. Mainly --sysroot is missing and g++ fails to find standard c++ headers (ex: cstdint).
I partially fixed the issue by overriding do_configure from cmake.bbclas simply by removing -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake. As a matter of fact CXXFLAGS are defined by toolchain.cmake as:
-march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0=/usr/src/debug/dnp3/2.2.0-r0 -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot-native= -fdebug-prefix-map=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot= -fvisibility-inlines-hidden -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot
So sysroot is defined (twice actually) as:
/home/star/moxa-build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/dnp3/2.2.0-r0/recipe-sysroot
but doesn't end up in the Makefile generated by cmake so I guess that something in toolchain.cmake makes the project's cmake configuration go south.
Turns out it was a cmake issue with the project itself. There was a merry mix-up between C and CXX flags in one of the included .cmake configuration file. I'll submit a pull request to the maintainer. CXXFLAGS being handled differently between the SDK (included directly in th CXX command) and by bitbake explained why it worked with the SDK (still not quite sure why it worked without toolchain.cmake though).
Thanks.
--sysroot is missing from CXXFLAGS because yocto stuffs it in the CXX variable itself. Note that alongside the sysroots directory yocto will have an environment-setup-XXX file which you should source. That's where all the sysroot stuff comes from.
Say I have a file structure like:
win32/ Something.cpp
linux/ Something.cpp
Something.h
main.cpp
How would I be able to implement:
UNAME = $(shell uname -s)
ifeq ($(UNAME), Linux)
OS = linux
else
OS = win32
endif
all:
g++ ?????
I've been at a loss for around an hour now. I've never attempted cross platform makefiles so I usually just let the IDE handle it but now I need to create it because the IDE isn't really cut out for cross platform projects.
PS: Something.h is just a class definition/prototype and the linux/ and win32/ source files are just providing a method for that class. Problem is that I get a compilation error saying the class is already declared if both exist without some form of build target or whatever.
Thanks.
Multi platform Makefiles are an advanced topic. You might want to take a look at scons. Anyway, here is how you could make your case work:
Build your list of sources depending on the $(UNAME):
UNAME = $(shell uname -s)
TARGET = myprogam
SRC_COMMON = main.cpp
ifeq ($(UNAME), Linux)
SRC_OS = $(wildcard linux/*.cpp)
else
SRC_OS = $(wildcard win32/*.cpp)
endif
SRC = $(SRC_COMMON) $(SRC_OS)
OBJ = $(SRC:.cpp=.o)
$(TARGET): $(OBJ)
Gooday everyone
I'm fairly new to ubuntu C programing although I'm
rather experienced in C programing in windows.
I have recently come accross a number of codes written
in 2005 which I'm interested in learning how they work.
Those codes needs BOOST library to compile, however they won't
compile on the newest BOOST version present on my ubuntu 12.04.
I set the gcc compiler on lenient so that it ignores all those error
messages. The code did compile and ran afterwards.
However, when I used GDB debugger to watch how the program flows
I noticed that there are likely errors in the way the program runs
due to using a different BOOST version rather than it's original. Hence
I like to install the BOOST version corresponding to the code I downloaded.
To do that, I installed Ubuntu 5.04 and BOOST 1.33.0 which seemed to have been created in late 2005. I downloaded it
but I didnt found any detailed instruction on how to install it.
Only vague description on using BOOST jam, I played around with BOOST
jam for quite awhile without success.
And this old BOOST does not have installation commands like
"sudo apt-install boost-dev" style option
Thus I like to ask if anyone can give a easy to understand step by step instruction
on how to install the BOOST library downloaded from the above link.
like.....
step1: download boost jam from boost webpage
step2: unpack it in home/boost/ then type make configure
...and so on...
Big thanks for any useful info.
New Contents appended here
in response to the comments given
Hi, I went through the info given by your link and
managed to run the boost library examples given by your link.
That is, I can compile a single cpp file with the command
g++ -I boost_1_33_0 test.cpp -o test
(I'm keeping the boost library and the cpp file to be compiled in the
same folder)
However, the program package I'm interested in is build with make (not cmake).
I have some experience writting cmake files but not make files.
And I do not see any link to boost library command in the make file of the
program package. The readme file only has one sentence that says I
need to have boost installed without explaining what that meant.
I assume it means that either I have to build and do makeinstall the boost or
I could add some lines in the makefile for a link. I thought
maybe you can quickly point out whats missing in the makefile.
The readme file:
To compile, go into the moses directory and do 'make'. You'll need the
latest boost libraries. If compilation still fails for weird reasons,
you could try g++ with the -fpermissive (newer versions reject lots of
code that was ok with older ones). If you are going to be making
changes and recompiling frequently you'll probably want to disable -O3
in the makefile (I use templates liberally, so -O3 really speeds up
the code, but really slows down compilation).
And the makefile:
CC = g++
PROJ_NAME = moses
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ -O3
src := $(wildcard *.cc) $(wildcard utils/*.cc) $(wildcard trees/*.cc) $(wildcard modeling/*.cc) $(wildcard fitness/*.cc) $(wildcard alignment/*.cc) $(wildcard main/*.cc) $(wildcard rewrite/*.cc) $(wildcard sim/*.cc) $(wildcard local/*.cc)
obj := $(patsubst %.cc,%.o,$(src))
all: $(PROJ_NAME)
%.o: %.cc
$(CC) $(COMP_FLAGS) $< -c -o $#
$(PROJ_NAME): $(obj)
$(CC) $(LINK_FLAGS) $^ -o $(PROJ_NAME)
run:
$(PROJ_NAME)
clean:
find -regex ".*~\|.*\.o"|xargs rm -f
rm -f $(PROJ_NAME)
rm -f $(PROJ_NAME).exe*
depend:
makedepend -Y -- $(COMP_FLAGS) -- $(src)
utils/exceptions.o: utils/exceptions.h utils/utils.h
utils/io_util.o: utils/io_util.h utils/tree.h utils/basic_types.h
# ......lots more lines like that.........
I have an old instruction flying around here for Boost 1.34.1, which reads like this (project-specific stuff cut away):
unpack boost sources
cd into tools/jam/src
run ./build.sh to build bjam
cd into the main source directory
tools/jam/src/bin.linux/bjam threading=multi --layout=system --toolset=gcc --without-python variant=release --prefix=/usr/local install
The --without-python was necessary as the target system didn't have Python installed, which caused the build to fail messily.
Obviously you can / need to fiddle with the individual settings (like threading support, release vs. debug variant) to suit your needs, but it should be a good starting point.
If you need ICU support (for Boost.Regex and Boost.Locale), it gets more complicated...
Note that the build process has changed over the years; you shouldn't use the same procedure for more up-to-date boost versions. It's just what I used back then.
Edit:
As for the second part of your question, the Makefile doesn't need to refer to Boost explicitly if boost is installed in the standard system directories.
You do not have to state -I /usr/include for compilation as that is searched automatically; the same goes for -L /usr/lib during linkage.
The fact that the author of the Makefile copied the compiler flags into the linker flags verbatim doesn't really help intuitivity either... ;-)
If you have Boost in a custom directory (either the headers only, or by stating a custom directory in the --prefix option of my build instructions), you need to make the following modifications (look for "boost"):
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -L /path/to/boost/libs -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ \
-I /path/to/boost/includes -O3
That should do the trick. As the Makefile does not link any of the Boost binaries (e.g. -l boost_program_options or somesuch), it seems that it makes use of the Boost headers only, which would make the -L /path/to/boost/libs part (and, actually, the whole compilation step detailed above) superfluous. You should be able to get away with simply unpacking the sources and giving the header directory as additional include directory using -I /path/to/boost/headers.