how to compile lapack so that it can be used correctly during installation of octave? - gcc

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"

Related

Error trying to install QCL (Quantum Computation Language) on Mac 10.11

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

CppuTest: undefined reference to pthread during final linking

I'm a newby in cppuTest and actually I'm trying to build the ./examples within the CppuTest root directory. Source and Test files are compiled without problems but I'm stucking on the final linking stage where I get this error:
C:\CppUTest\cpputest-3.7.1\examples>make
compiling AllTests.cpp
compiling CircularBufferTest.cpp
compiling EventDispatcherTest.cpp
compiling HelloTest.cpp
compiling MockDocumentationTest.cpp
compiling PrinterTest.cpp
compiling CircularBuffer.cpp
compiling EventDispatcher.cpp
compiling Printer.cpp
compiling hello.c
Building archive lib/libCppUTestExamples.a
a - objs/ApplicationLib/CircularBuffer.o
a - objs/ApplicationLib/EventDispatcher.o
a - objs/ApplicationLib/Printer.o
a - objs/ApplicationLib/hello.o
Linking CppUTestExamples_tests
../lib/libCppUTest.a(UtestPlatform.cpp.obj): In function `PThreadMutexCreate':
c:/CppUTest/cpputest-3.7.1/src/Platforms/Gcc/UtestPlatform.cpp:248: undefined reference to `_imp__pthread_mutex_init'
../lib/libCppUTest.a(UtestPlatform.cpp.obj): In function `PThreadMutexLock':
c:/CppUTest/cpputest-3.7.1/src/Platforms/Gcc/UtestPlatform.cpp:255: undefined reference to `_imp__pthread_mutex_lock'
../lib/libCppUTest.a(UtestPlatform.cpp.obj): In function `PThreadMutexUnlock':
c:/CppUTest/cpputest-3.7.1/src/Platforms/Gcc/UtestPlatform.cpp:260: undefined reference to `_imp__pthread_mutex_unlock'
../lib/libCppUTest.a(UtestPlatform.cpp.obj): In function `PThreadMutexDestroy':
c:/CppUTest/cpputest-3.7.1/src/Platforms/Gcc/UtestPlatform.cpp:266: undefined reference to `_imp__pthread_mutex_destroy'
collect2.exe: error: ld returned 1 exit status
make: *** [CppUTestExamples_tests] Error 1
I'm using MinGW on Windows 7. The MinGW contains also the pthread.a library. My makefil look as follows:
#---------
#
# CppUTest Examples Makefile
#
#----------
#Set this to # to keep the makefile quiet
ifndef SILENCE
SILENCE = #
endif
#--- Inputs ----#
COMPONENT_NAME = CppUTestExamples
CPPUTEST_HOME = ..
CPPUTEST_USE_EXTENSIONS = Y
CPP_PLATFORM = Gcc
CFLAGS = -Dmalloc=cpputest_malloc -Dfree=cpputest_free
CPPFLAGS =
GCOVFLAGS = -fprofile-arcs -ftest-coverage
LDFLAGS = -lpthread
#USER_LIBS = -lpthread
# This line is overriding the default new macros. This is helpful
# when using std library includes like <list> and other containers
# so that memory leak detection does not conflict with stl.
CPPUTEST_MEMLEAK_DETECTOR_NEW_MACRO_FILE = -include ApplicationLib/ExamplesNewOverrides.h
SRC_DIRS = \
ApplicationLib
TEST_SRC_DIRS = \
AllTests
INCLUDE_DIRS =\
.\
ApplicationLib\
$(CPPUTEST_HOME)/include\
include $(CPPUTEST_HOME)/build/MakefileWorker.mk
As you can see the pthread lib is given to the linker with the LDFLAGS....
somebody similar experience? or maybe knows where the problem is?
Will be thankful for any tips!
thx to #Keith Marshall and #MadScientist,
so instead of
LDFLAGS = -lpthread
I used:
LD_LIBRARIES += -lpthread
and placed this line directly before:
include $(CPPUTEST_HOME)/build/MakefileWorker.mk
Now it works.
As can be seen in the Catalogue of Built-In Rules:
Linking a single object file
n is made automatically from n.o by running the linker (usually called
ld) via the C compiler. The precise recipe used is:
$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
and Variables Used by Implicit Rules:
LDFLAGS
Extra flags to give to compilers when they are supposed to invoke the linker,
ld, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable
instead.
So in this case -lpthread should be set or added to LDLIBS, not LDFLAGS.

How to stop CMake appending C compiler flags

I converted an old style makefile to a CMake CMakeLists.txt file so that I can load a project into JetBrain's new CLion IDE.
I thought it would be easy, but I'm stuck at the point of CMake appending some custom compiler flags to the compilation command which cause a compilation error. I don't have enough knowledge of CMake to solve this issue.
Here is the original makefile.
# makefile
# Main Filename to be compiled
MAINFILE = TestProgram
# Paths
DRIVE := C:
COMPILERROOT := $(DRIVE)/GNUHC11
COMPILERPATH := $(COMPILERROOT)/bin
GELROOT := $(DRIVE)/library/gel-hc1x-1.6.1
GELINCLUDESDIR := $(GELROOT)/include
# Compiler, Linker, Object Copy, and Object Dump path
CC := $(COMPILERPATH)/m6811-elf-gcc # compiler
OC := $(COMPILERPATH)/m6811-elf-objcopy # object copy
OD := $(COMPILERPATH)/m6811-elf-objdump # object dump
# Includes
GELINCLUDES += -I$(GELINCLUDESDIR) -I$(GELINCLUDESDIR)/asm-m68hc11/arch-32k
# Compiler Flags
CFLAGS += -Os # turn on optimizer
CFLAGS += -mshort # consider type int to be 16 bits
CFLAGS += -Wl,-m,m68hc11elfb # build for elf file and use memory.x for memory map
CFLAGS += -I. $(GELINCLUDES) # Add current dir and gel library for includes
CFLAGS += -Dmc6811 # Add define to define the processor architecture for gel includes
# C Source codes to be compiled
SRC1 = $(MAINFILE).c
SRC2 = Interrupts.c
SRC3 = Utilities.c
# C Header files dependencies
HDR1 = $(MAINFILE).h
HDR2 = Interrupts.h
HDR3 = Utilities.h
SRCS = $(SRC1) $(SRC2) $(SRC3)
HDRS = $(HDR1) $(HDR2) $(HDR3)
# Elf file to be generated
ELF1 = $(SRC1:.c=.elf)
# Generate Bin file for programming & Assembly dump
$(MAINFILE).bin : $(ELF1)
$(OC) -O binary $(ELF1) $(MAINFILE).bin
$(OD) -xDC --section=.text --section=.vectors $(ELF1) >$(MAINFILE).dump
# Full compile and link
$(ELF1) : $(SRCS) $(HDRS)
$(CC) $(CFLAGS) -o $(ELF1) $(SRCS)
clean ::
del *.dump
del *.elf
del *.bin
And here is my attempt at the CMakeLists.txt file.
cmake_minimum_required(VERSION 2.8.4)
# program names
set(HC11C m6811-elf-gcc.exe)
set(OBJCOPY m6811-elf-objcopy.exe)
set(OBJDUMP m6811-elf-objdump.exe)
# Important project paths
set(LIB_INC_PATH "C:/library/gel-hc1x-1.6.1/include"
"C:/library/gel-hc1x-1.6.1/include/asm-m68hc11/arch-32k")
set(HC11C_PATH "C:/GNUHC11/bin")
# Sets the compiler
# Needs to come before the project function
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER "${HC11C_PATH}/${HC11C}")
set(MAIN_FILE "TestProgram")
project(${MAIN_FILE})
# Files to be compiled
set(BASE_PATH "${${PROJECT_NAME}_SOURCE_DIR}")
set(INC_PATH "${BASE_PATH}")
set(SRC_PATH "${BASE_PATH}")
set(SRC_FILES "${SRC_PATH}/${MAIN_FILE}.c"
"${SRC_PATH}/Interrupts.c"
"${SRC_PATH}/Utilities.c")
# Attempt to clear the other spurious compiler flags that I don't want,
# and which cause a compiler arguments error.
# This doesn't seem to work - the defaults still appear.
set(CMAKE_C_FLAGS_DEBUG "")
set(CMAKE_C_FLAGS_RELEASE "")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "")
set(CMAKE_C_FLAGS_MINSIZEREL "")
# Compiler flags
set(CWARN "-Wl,-m,m68hc11elfb") # build for elf file and use memory.x for memory map
set(CTUNING "-mshort") # consider type int to be 16 bits
set(COPT "-Os") # turn on optimizer
set(CDEFS "-Dmc6811") # Add define to define the processor architecture for gel includes
set(CFILES "${MAIN_FILE}.c Interrupts.c Utilities.c")
set(CFLAGS "${CDEFS} ${COPT} ${CWARN} ${CTUNING} ${CFILES}")
set(CMAKE_C_FLAGS "${CFLAGS}")
# Project setup
include_directories(${INC_PATH} ${LIB_INC_PATH})
add_executable(${MAIN_FILE} ${SRC_FILES})
set_target_properties(${MAIN_FILE} PROPERTIES OUTPUT_NAME "${MAIN_FILE}.elf")
# Compiling targets
add_custom_target(main ALL ${OBJCOPY} -O binary "${MAIN_FILE}.elf" "${MAIN_FILE}.bin" DEPENDS ${MAIN_FILE})
add_custom_target(dump ALL ${OBJDUMP} -xDC --section=.text --section=.vectors "${MAIN_FILE}.elf" > "${MAIN_FILE}.dump" DEPENDS main)
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${MAIN_FILE}.dump;${MAIN_FILE}.elf;${MAIN_FILE}.bin")
# Config logging
message("* ")
message("* Project Name:\t${PROJECT_NAME}")
message("* Project Source:\t${SRC_PATH}")
message("* Project Include:\t${INC_PATH}")
message("* Library Include:\t${LIB_INC_PATH}")
message("* ")
message("* Project Source Files:\t${SRC_FILES}")
message("* MAIN_FILE variable:\t${MAIN_FILE}")
message("* ")
message("* C Flags:\t${CMAKE_C_FLAGS}")
message("* ")
Here is the generated compilation command:
C:\GNUHC11\bin\m6811-elf-gcc.exe "-xc" "-Dmc6811" "-Os" "-Wl,-m,m68hc11elfb" "-mshort" "TestProgram.c" "Interrupts.c" "Utilities.c" "-IC:\\DEVELO~1\\source" "-IC:\\library\\gel-hc1x-1.6.1\\include" "-IC:\\library\\gel-hc1x-1.6.1\\include\\asm-m68hc11\\arch-32k" "-v" "-dD" "-E" "-D___CIDR_IGNORE_DEFINITIONS_START"
It would work but for the auto appended "-E" compiler flag at the end which I don't want. The other appended flags "-v" "-dD" and '-D___CIDR..." are also unwanted but do not cause a compilation error like "-E" does. How can I turn these appended flags off?
Thanks in advance for any help.
It seems you are cross-compiling, so the preferred cmake configuration is a bit different than normal.
See http://www.vtk.org/Wiki/CMake_Cross_Compiling for details, pay attention to the "toolchain file".
I have no idea regarding the auto-appended flags.
You can also have a look at the generated CMakeCache.txt file, either with any editor, from CLion itself, or with cmake-gui.
Remember that CLion copies your CMakeLists.txt in a funky temporary directory and runs cmake off the temporary directory, if you want to look at CMakeCache.txt by hand.
What I suggest is to put aside CLion while you are debugging the CMakeLists.txt, and just use cmake or cmake-gui directly from the shell.
Don't give up, both cmake and CLion are two very good programs IMHO :-)
There doesn't seem to be too much information on this one, but I also ran into this issue. In cmake if you do something like
target_compile_options(game PRIVATE /W4 /WX /wd4100 /wd4200 /wd4201 /FAs /EHsc /Gh /GH)
this will add those options for all compilers in that target.
You can use a generator if you want to add language specific options, so I changed it to:
target_compile_options(game PRIVATE
$<$<COMPILE_LANGUAGE:C>:/W4 /WX /wd4100 /wd4200 /wd4201 /FAs /EHsc /Gh /GH>)
which works.

Error: bad value for -march= switch

I wrote a Makefile and I can't get it to work. I have an option which is supposed to select which processor to compile to. However, when I run make from the commandline it says:
tandex#tandex-P-6860FX:~/emulators/nintendo sdks/3DS SDK [HomeBrew]$ make
gcc -march=arm7tdmi -static -fexceptions -fnon-call-exceptions -fstack-check test.c -c
test.c:1:0: error: bad value (arm7tdmi) for -march= switch
make: *** [ALL] Error 1
But in the man pages for gcc, it states that arm7tdmi is a permissible value. Am I missing something?
Makefile:
#3DS Compilation Makefile (c) TanDex (TEQ)RunawayFreelancers
#
#Version 0.99 (Alpha) For *nix Devices
#
#Please Check Back Soon for 3rd SDK
#SELECT THE COMPILER TO USE! GCC RECOMMENDED!
#FOR SANITY SAKE, USE C FILES WITH GCC AND CPP FILES WITH G++
CC=gcc
#CC=g++
#OBJECTCOPY REFERENCE, DO NOT REMOVE
OBJC=objcopy
OBJREFS= -O Binary
#SELECT THE PROCESSOR TO TUNE IT TO. ARMV7 (Nintendo DS) or ARMV9(Nintendo DS
(Graphical Support))
#or ARM11 Core ARM1176JZ-S and ARM1176JZF-S (3DS Processor? Not Sure if Correct. Try
and see if they Work?)
#
#NOTE: DS GAMES REQUIRE BOTH A ARM7 AND ARM9 BINARY. RUN THIS TWICE (ONCE FOR EACH)
#
#UNCOMMENT FOR PROCESOR
PROCESSOR=arm7tdmi
#PROCESSOR=arm946e-s
#PROCESSOR=arm1176jz-s
#PROCESSOR=arm1176jzf-s
#FILES
#
#PLACE ALL OF THE FILES HERE, THAT ARE BEING COMPILED!
FILES=test.c
#SET BIN FILE NAME BASED ON PROCESSOR SELECTED
ifeq($(PROCESSOR),arm7tdmi)\
NAME=ARM7.BIN
ifeq($(PROCESSOR), arm946e-s)\
NAME=ARM9.BIN
ifeq($(PROCESSOR), arm1176jz-s)\
NAME=ARM11.BIN
ifeq($(PROCESSOR), arm1176jzf-s)\
NAME=ARM11.BIN
#CREATE OBJECTS
ifeq($(CC), gcc)\
OBJECTS=$(FILES:.c=.o)
ifeq($(CC), g++)\
OBJECTS=$(FILES:.cpp=.o)
#FLAGS! DO NOT CHANGE THESE!!!!!!!!!!! THAT MEANS YOU!!!!!
#
#FOR THOSE WHO WANT TO KNOW WHAT THESE DO, HERE THEY ARE:
#-mtune=$(PROCESSOR) FORE THE COMPILER TO TUNE OUTPUT TO THE SPECIFIED
PROCESSOR
#-static REQUIRED FOR CLEAN BINARY OUTPUT?? (NOT SURE WHAT THIS
DOES, BUT WAS SUGESTED ON A POST ON STACKOVERFLOW)
#-fexceptions FORCE EXCEPTIONS
#-fnon-call-exceptions FORCE EXCEPTIONS TO ONLY BE RETURNED BY THE SYSTEM
(MEMORY AND FPU INSTRUTIONS FOR EXAMPLE)
#-fstack-check FORCE STACK CHECKING (DS / 3DS USE AWKWARD STACK
IMPLEMENTATION)
CFLAGS=-march=$(PROCESSOR) -static -fexceptions -fnon-call-exceptions -fstack-check
ALL:
$(CC) $(CFLAGS) $(FILES) -c
.c.o:
$(OBJC) $(OBJREFS) $(OBJECTS) $(NAME)
.cpp.o:
$(OBJC) $(OBJREFS) $(OBJECTS) $(NAME)
You are probably not calling the right gcc. You seem to be calling the gcc installed in your system, rather than the one that comes with the 3DS SDK.
It appears the problem is with -march=arm7tdmi.
I think the workaround is to avoid using -march=arm7tdmi; and use -march=cpu-type, where cpu-type is one of the ones listed at 3.17.4 ARM Options of the GCC manual.
Here's part of the page:
-march=name
This specifies the name of the target ARM architecture. GCC uses this name to determine what kind of instructions it can emit when
generating assembly code. This option can be used in conjunction with
or instead of the -mcpu= option. Permissible names are: ‘armv2’,
‘armv2a’, ‘armv3’, ‘armv3m’, ‘armv4’, ‘armv4t’, ‘armv5’, ‘armv5t’,
‘armv5e’, ‘armv5te’, ‘armv6’, ‘armv6j’, ‘armv6t2’, ‘armv6z’,
‘armv6kz’, ‘armv6-m’, ‘armv7’, ‘armv7-a’, ‘armv7-r’, ‘armv7-m’,
‘armv7e-m’, ‘armv7ve’, ‘armv8-a’, ‘armv8-a+crc’, ‘iwmmxt’, ‘iwmmxt2’,
‘ep9312’.

Adding a directory for the headers in a Makefile

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.
]

Resources