Iphone makefile dropping last quote on loading - iphone

I am currently trying to build an iPhone app that I have developed using the iPhone toolchain. When I finished creating the makefile it was giving me this error when it tried to load my .o files together:
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
Upon looking at the shell code it was trying to execute, I determined that it dropped the last quote so I made a quick fix to my makefile. Upon loading, it gave me the following error:
Undefined symbols:
"_main", referenced from:
__start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** ["Autotune] Error 1
If I read this correctly it cannot find my main function, but it is clearly defined in main.mm. I would like to keep my project closed source, but I am willing to show certain, non-vital parts of my code. I don't see why it is not compiling; it worked fine on Xcode. Did my change to the Makefile somehow cause it to not load the _main symbol? How can I fix this problem? I am quite stumped.
Here is my Makefile:
PROJECTNAME="MyAppName"
APPFOLDER=$(PROJECTNAME).app
INSTALLFOLDER=$(PROJECTNAME).app
CC=arm-apple-darwin9-gcc
LD=$(CC)
LDFLAGS = -arch arm -lobjc
LDFLAGS += -framework CoreFoundation
LDFLAGS += -framework Foundation
LDFLAGS += -framework UIKit
LDFLAGS += -framework QuartzCore
LDFLAGS += -framework CoreGraphics
LDFLAGS += -framework CoreAudio
LDFLAGS += -framework AudioToolbox
LDFLAGS += -framework AVFoundation
LDFLAGS += -L"/usr/lib"
LDFLAGS += -F"/System/Library/Frameworks"
LDFLAGS += -F"/System/Library/PrivateFrameworks"
LDFLAGS += -bind_at_load
LDFLAGS += -multiply_defined suppress
CFLAGS = -I"/var/include"
CFLAGS += -I"/usr/include"
CFLAGS += -I"/var/include/c++/4.0.0"
CFLAGS += -I"/var/include/c++/4.0.0/arm-apple-darwin9"
CFLAGS += -I"./Classes"
CFLAGS += -F"/System/Library/Frameworks"
CFLAGS += -F"/System/Library/PrivateFrameworks"
CFLAGS += -DDEBUG -Wall
CFLAGS += -DMAC_OS_X_VERSION_MAX_ALLOWED=1050
BUILDDIR=./build/2.0
SRCDIR=./Classes
RESDIR=./Resources
OBJS=$(patsubst %.m,%.o,$(wildcard $(SRCDIR)/*.m))
OBJS+=$(patsubst %.mm,%.o,$(wildcard $(SRCDIR)/*.mm))
OBJS+=$(patsubst %.c,%.o,$(wildcard $(SRCDIR)/*.c))
OBJS+=$(patsubst %.cpp,%.o,$(wildcard $(SRCDIR)/*.cpp))
RESOURCES=$(wildcard $(RESDIR)/*)
all: dist
CFLAGS += -include Prefix.h
$(PROJECTNAME): $(OBJS)
$(LD) $(LDFLAGS) -o $# $^
%.o: %.m
$(CC) -c $(CFLAGS) $< -o $#
%.o: %.mm
$(CC) -c $(CFLAGS) $< -o $#
%.o: %.c
$(CC) -c $(CFLAGS) $< -o $#
%.o: %.cpp
$(CC) -c $(CFLAGS) $< -o $#
dist: $(PROJECTNAME)
/bin/rm -rf $(BUILDDIR)
/bin/mkdir -p $(BUILDDIR)/$(APPFOLDER)
/bin/cp $(RESDIR)/* $(BUILDDIR)/$(APPFOLDER)
/bin/cp Info.plist $(BUILDDIR)/$(APPFOLDER)/Info.plist
#echo "APPL????" > $(BUILDDIR)/$(APPFOLDER)/PkgInfo
/usr/bin/ldid -S $(PROJECTNAME)
/bin/cp $(PROJECTNAME) $(BUILDDIR)/$(APPFOLDER)
install: dist
/bin/cp -r $(BUILDDIR)/$(APPFOLDER) /Applications/$(INSTALLFOLDER)
#echo "Application $(INSTALLFOLDER) installed"
killall SpringBoard
uninstall:
/bin/rm -fr /Applications/$(INSTALLFOLDER)
killall SpringBoard
reinstall: dist
/bin/rm -fr /Applications/$(INSTALLFOLDER)
/bin/cp -r $(BUILDDIR)/$(APPFOLDER) /Applications/$(INSTALLFOLDER)
#echo "Application $(INSTALLFOLDER) installed"
clean:
#rm -f $(SRCDIR)/*.o
#rm -rf $(BUILDDIR)
#rm -f $(PROJECTNAME)
It is important to note that Prefix.h used to be a precompiled header but I just changed it to a header file and told make to include it in all my source files.
The quick fix that I made for the problem of not including the final quote was:
changing:
$(PROJECTNAME): $(OBJS)
$(LD) $(LDFLAGS) -o $# $^
to:
$(PROJECTNAME): $(OBJS)
$(LD) $(LDFLAGS) -o $# $^"
To restate my question after that long post. Did my change to the Makefile somehow cause it to not load the _main symbol?

I figured it out my actual app name given by PROJECTNAME had a space in it. I removed the space my quick fix and changed LD from apple-arm-darwin9-gcc to apple-arm-darwin9-g++. after that it worked.

Related

How to make a Linux Makefile work on Windows?

(Disclaimer: I am not at all a computer science genius, far from that. I may use bad terminology and I appologize.)
I need to run some tests using the google test library and I was provided with a Makefile to handle the execution but it won't run on my Windows machine (I use Visual Studio). It was made for a Linux environment so I'm not sure what i would need to modify in order to run it. I have used MinGW to run Makefiles of my own making in the past.
Here's how the Makefile looks like:
CC=g++
CFLAGS=-c -Wall -ggdb -I.
LDFLAGS=
SOURCES=main.c singlelinklist.c
TESTS=single_test.cpp
#TODO: Need a more elegant way of specifying objects and tests
GTESTDIR=~/environment/googletest
OBJECTS=$(SOURCES:.cpp=.o)
FLAGS = -Iinclude
#all: $(SOURCES) $(EXECUTABLE)
# These next lines do a bit of magic found from http://stackoverflow.com/questions/2394609/makefile-header-dependencies
# Essentially it asks the compiler to read the .cpp files and generate the needed .h dependencies.
# This way if any .h file changes the correct .cpp files will be recompiled
depend: .depend
.depend: $(SOURCES)
rm -f ./.depend
$(CC) $(CFLAGS) -MM $^ >> ./.depend;
include .depend
# End .h file magic
#$(EXECUTABLE): $(OBJECTS)
# $(CC) $(LDFLAGS) $(OBJECTS) -o $#
#.cpp.o:
# $(CC) $(CFLAGS) $< -o $#
clean:
# rm -rf *o $(EXECUTABLE) test_executable
rm -f ./.depend
rm $(GTESTDIR)/libgtest.a
rm $(GTESTDIR)/gtest-all.o
# Google test section
$(GTESTDIR)/libgtest.a:
$(CC) -isystem $(GTESTDIR) -I $(GTESTDIR) -pthread -c $(GTESTDIR)/gtest/gtest-all.cc -o $(GTESTDIR)/gtest-all.o
ar -rv $(GTESTDIR)/libgtest.a $(GTESTDIR)/gtest-all.o
# This will also recompile if any source file is changed.
test_executable: $(GTESTDIR)/libgtest.a $(TESTS) depend
$(CC) -isystem $(GTESTDIR) -pthread -ggdb $(TESTS) $(GTESTDIR)/gtest/gtest_main.cc $(GTESTDIR)/libgtest.a -o test_executable
test: test_executable
./test_executable --gtest_print_time=0
And here's how my workspace is structured.
(Seems like I can't embed pictures).

Makefile with multiple outcomes

This is my first attempt to write a makefile and therefore there is a lot of room for improvements. I need to generate several mex functions for matlab on mac using the package sedumi and intel compiler studio.
Here is the makefile
# define matlab dir
MDIR = /Applications/MATLAB_R2017b.app
# compiles mex files using g++
#CC = gcc
# compiler flags for g++
#CCFLAGS = -O3 -fpic
# to use the intel compiler instead, uncomment CC and CCFLAGS below:
# compiles mex file using the intel compiler
CC = icc
# compiler flags for intel compiler
CCFLAGS = -O3 -fPIC -D__amd64
# Figure out which platform we're on
UNAME = $(shell uname -s)
# Linux
ifeq ($(findstring Linux,${UNAME}), Linux)
# define which files to be included
CINCLUDE = -I$(MDIR)/extern/include -Ic++ -shared
# define extension
EXT = mexa64
endif
# Mac OS X
ifeq ($(findstring Darwin,${UNAME}), Darwin)
# define which files to be included
CINCLUDE = -L$(MDIR)/bin/maci64 -Ic++ -shared -lmx -lmex -lmat -lmwblas
# define extension
EXT = mexmaci64
# CCFLAGS += -std=c++11
endif
SRC:=$(wildcard *.c)
*.o: $(SRC)
for i in $(SRC) ; do \
$(CC) $(CCFLAGS) -I$(MDIR)/extern/include -c -Ic++ $$i -o $${i%.c}.o; \
done
OBJ0:=bwblkslv.o sdmauxFill.o sdmauxRdot.o
OBJ1:=choltmpsiz.o
all:
$(CC) $(CCFLAGS) $(CINCLUDE) $(OBJ0) -o bwblkslv.$(EXT)
$(CC) $(CCFLAGS) $(CINCLUDE) $(OBJ1) -o choltmpsiz.$(EXT)
# clean up
clean:
rm -f *.o *.$(EXT)
As it is, Makefile works just fine. make and then make all return the mex functions needed within matlab.
I have OBJ0 to OBJ37 and although adding the lines solves the problem I wonder if there is a simpler way to accomplish the same results.
Many thanks.
Ed
PS. Thanks to the author of https://github.com/jtilly/mex for parts of the makefile.
There are several aspects that you could improve:
Use make automatic variables ($#, $<, $^...)
Use a more make-oriented style for your C compilations, thanks to a make pattern rule:
SRC := $(wildcard *.c)
OBJ := $(patsubst %.c,%.o,$(SRC))
%.o: %.c
$(CC) $(CCFLAGS) -I$(MDIR)/extern/include -c -Ic++ $< -o $#
This has several advantages over you shell loop. The most important one being that only one compilation is run when only one C file changes. With your solution all C files are recompiled when only one changes. Moreover, *.o is a wildcard that expands to existing object files. Not what you want, usually. Note that in your case you could also use a static pattern rule:
$(OBJ): %.o: %.c
$(CC) $(CCFLAGS) -I$(MDIR)/extern/include -c -Ic++ $< -o $#
which looks almost the same but limits the rule to the specified list of targets $(OBJ).
Use a macro and foreach-eval-call to instantiate the linker rules:
.PHONY: all clean
EXTS :=
# $(1): variable name
define MY_rule
$(1)_EXT := $$(patsubst %.o,%.$$(EXT),$$(firstword $$($(1))))
EXTS += $$($(1)_EXT)
$$($(1)_EXT): $$($(1))
$$(CC) $$(CCFLAGS) $$(CINCLUDE) $$^ -o $$#
endef
OBJVARS := OBJ0 OBJ1 ... OBJ37
OBJ0 := bwblkslv.o sdmauxFill.o sdmauxRdot.o
OBJ1 := choltmpsiz.o
$(foreach v,$(OBJVARS),$(eval $(call MY_rule,$(v))))
all: $(EXTS)
clean:
rm -f $(OBJ) $(EXTS)
Note the $$ to escape the first expansion added by eval. For example, the first iteration of foreach instantiates the following rule:
OBJ1_EXT := $(patsubst %.o,%.$(EXT),$(firstword $(OBJ1))
EXTS += $(OBJ1_EXT)
$(OBJ1_EXT): $(OBJ1)
$(CC) $(CCFLAGS) $(CINCLUDE) $^ -o $#
An easy way to design the macro consists in writing first what you want with, for instance, the OBJ1 variable, replace each $ by $$ and finally replace OBJ1 by $(1).

Linking OpenMP with Matlab mex files [duplicate]

I've written a program of the following form:
#include "stuff_I_need.h"
int main(){
construct_array(); // uses OpenMP pragma's
print_array();
return(0);
}
that compiles, links, and runs correctly with the following command:
`gcc44 -I/home/matteson/sundials/include/ main.c -lm -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial -fopenmp -o /home/matteson/MPI_test/CVODE_test/main_test`
"gcc44" is simply gcc version 4.4 and is named like this because it's being compiled on a cluster that maintains several versions of gcc. The libraries sundials_cvode and sundials_nvecserial are used in the solving of several differential equations during the construction of the array.
Now when I want to transfer over to Matlab and try to compile the mex file of the form:
#include "stuff_I_need.h"
void mexFunction(int nlhs,mxArray* plhs[], int nrhs, const mxArray* prhs[]){
construct_array(); // uses OpenMP pragma's
print_array();
}
and try to compile with the following command in Matlab:
>> mex -v CC="gcc44" CFLAGS="\$CFLAGS -I/home/matteson/sundials/include/ -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial" mex_cvode.c
I get the following messages culminating in a link error:
-> mexopts.sh sourced from directory (DIR = $HOME/.matlab/$REL_VERSION)
FILE = /home/matteson/.matlab/R2010b/mexopts.sh
----------------------------------------------------------------
-> MATLAB = /misc/linux/64/opt/pkg/matlab/R2010b
-> CC = gcc44
-> CC flags:
CFLAGS = -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -L/home/matteson/sundials/lib -lsundials_nvecserial
CDEBUGFLAGS = -g
COPTIMFLAGS = -O -DNDEBUG
CLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
arguments = -DMX_COMPAT_32
-> CXX = g++
-> CXX flags:
CXXFLAGS = -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread
CXXDEBUGFLAGS = -g
CXXOPTIMFLAGS = -O -DNDEBUG
CXXLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm
arguments = -DMX_COMPAT_32
-> FC = g95
-> FC flags:
FFLAGS = -fexceptions -fPIC -fno-omit-frame-pointer
FDEBUGFLAGS = -g
FOPTIMFLAGS = -O
FLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm
arguments = -DMX_COMPAT_32
-> LD = gcc44
-> Link flags:
LDFLAGS = -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmpofopenmp
LDDEBUGFLAGS = -g
LDOPTIMFLAGS = -O
LDEXTENSION = .mexa64
arguments =
-> LDCXX =
-> Link flags:
LDCXXFLAGS =
LDCXXDEBUGFLAGS =
LDCXXOPTIMFLAGS =
LDCXXEXTENSION =
arguments =
----------------------------------------------------------------
Warning: You are using gcc version "4.4.4". The version
currently supported with MEX is "4.3.4".
For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release/
-> gcc44 -c -I/misc/linux/64/opt/pkg/matlab/R2010b/extern/include -I/misc/linux/64/opt/pkg/matlab/R2010b/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -L/home/matteson/sundials/lib -lsundials_nvecserial -DMX_COMPAT_32 -O -DNDEBUG "mex_cvode.c"
-> gcc44 -O -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmpofopenmp -o "mex_cvode.mexa64" mex_cvode.o -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
mex_cvode.o: In function `mexFunction':
mex_cvode.c:(.text+0x2b2): undefined reference to `N_VNew_Serial'
mex_cvode.c:(.text+0x2db): undefined reference to `N_VNew_Serial'
mex_cvode.c:(.text+0x35b): undefined reference to `CVodeCreate'
mex_cvode.c:(.text+0x39c): undefined reference to `CVodeInit'
mex_cvode.c:(.text+0x3dd): undefined reference to `CVodeSVtolerances'
mex_cvode.c:(.text+0x412): undefined reference to `CVodeSetUserData'
mex_cvode.c:(.text+0x449): undefined reference to `CVDense'
mex_cvode.c:(.text+0x482): undefined reference to `CVDlsSetDenseJacFn'
mex_cvode.c:(.text+0x50c): undefined reference to `CVode'
mex_cvode.c:(.text+0x5b4): undefined reference to `N_VDestroy_Serial'
mex_cvode.c:(.text+0x5c0): undefined reference to `N_VDestroy_Serial'
mex_cvode.c:(.text+0x5cc): undefined reference to `CVodeFree'
collect2: ld returned 1 exit status
mex: link of ' "mex_cvode.mexa64"' failed.
??? Error using ==> mex at 208
Unable to complete successfully.
Somehow, I'm not giving the correct flags to link appropriately. As I get the same set of errors (plus a few more) if I remove the commands to link in the gcc44 command, I'm pretty sure that I'm not getting the compiler to "see" the libraries.
My questions are :
If my analysis of the error is correct, what flags do I need to pass to the mex compilation command to successfully link?
Alternatively, what are the gcc flags to compile and link outside of the Matlab environment to compile a .mex64 executable?
If my analysis is wrong, where to go from here?
I think I've ruled out the unsupported compiler warning since I've been able to compile simple mex with OpenMP programs using gcc 4.4, but these did not have to link against anything except the math library. Also, if I compile with version gcc version 4.1.2 or 4.3.4 with or without the "-fopenmp" flags I get the same error.
In the end I do need version 4.4 because of certain OpenMP support that did not appear in prior versions.
Thanks in advance for the help.
--Andrew
Edits: (#KWATFORD)
So I tried the command with the statements outside the the quotes, and got the error:
-> gcc44 -c -I/home/matteson/sundials/include/ -I/misc/linux/64/opt/pkg/matlab/R2010b/extern/include -I/misc/linux/64/opt/pkg/matlab/R2010b/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -fopenmp -DMX_COMPAT_32 -O -DNDEBUG "mex_cvode.c"
-> gcc44 -O -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmp -o "mex_cvode.mexa64" mex_cvode.o -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
/usr/bin/ld: /home/matteson/sundials/lib/libsundials_cvode.a(cvode.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/home/matteson/sundials/lib/libsundials_cvode.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
mex: link of ' "mex_cvode.mexa64"' failed.
??? Error using ==> mex at 208
Unable to complete successfully.
I'm a bit confused about the suggestion to recompile with "-fPIC" because when I look at the gcc44 command I see the -fPIC as an option.
Are they saying to recompile the library with -fPIC?
I don't have the source for the library, if the suggestion is to recompile the library is there a workaround?
What does "relocation against local object" mean?
My continued thanks.
Try not putting the -l, -L, or -I arguments in those environment variables. The mex function will handle those types of arguments directly. So perhaps something like:
mex -v CC="gcc44" CFLAGS="\$CFLAGS -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp" -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial mex_cvode.c
Kwatford put me on the right track with the second question. I was able to get the mex command to work by rebuilding the sundials solver with shared libraries. Specifically, I built with:
% make distclean
% ./configure --prefix=/home/matteson/sundials --enable-shared
% make
% make install
Also, thanks to kwatford for the fix to the original by calling:
mex -v CC="gcc44" CFLAGS="\$CFLAGS -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp" -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial mex_cvode.c
since mex knows how to handle the -L and -I.
Matlab uses its own libstdc and libstdc++.
The shortcut would be to do a symbolink to those libraries to the gcc44 libraries that you want to use.
But this may not be the desired way to go. You could try compiling outside matlab prompt and see if it still fails compilation first.

Not able to link libsvn_delta-1.a when compiling svn_swig_perl in msys

Trying to compile perl svn binding for msys. But when compiling the swig perl lib_core.dll it complains reference not found for _svn_delta_noop_window_handler and _svn_delta_default_editor in libsvn_swig_perl-1.a. Both function coming from libsvn_delta-1.a.
I should recompile and make sure the libsvn_swig_perl-1.a properly link with libsvn_delta-1.a? Or it doesn't matter as long as during building lib_core.dll it can link the missing static library?
I really have no idea how to solve this issue.
below are the full log when compile the lib_core.dll:
ld2 -s core.o -o blib/arch/auto/SVN/_Core/_Core.dll \
/usr/lib/perl5/5.8.8/msys/CORE/libperl.dll.a -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_client/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_delta/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_repos/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_wc/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_diff/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_subr/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_local/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_svn/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_neon/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_util/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_fs_util-1 -lsvn_swig_perl-1 -lapr-1 -lintl -lz -laprutil-1 -lexpat -lperl -L/lib/perl5/5.8.8/msys/CORE \
gcc -shared -o _Core.dll -Wl,--out-implib=lib_Core.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s core.o /usr/lib/perl5/5.8.8/msys/CORE/libperl.dll.a -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_client/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_delta/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_repos/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_wc/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_diff/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_subr/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_local/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_svn/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_neon/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_util/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_fs_util-1 -lsvn_swig_perl-1 -lapr-1 -lintl -lz -laprutil-1 -lexpat -lperl -L/lib/perl5/5.8.8/msys/CORE
Creating library file: lib_Core.dll.a
/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/bindings/swig/perl/libsvn_swig_perl/.libs/libsvn_swig_perl-1.a(swigutil_pl.o.b): In function `thunk_apply_textdelta':
/usr/src/subversion16/subversion-1.6.17-3-msys-src/subversion-1.6.17/subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c:703: undefined reference to `_svn_delta_noop_window_handler'
/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/bindings/swig/perl/libsvn_swig_perl/.libs/libsvn_swig_perl-1.a(swigutil_pl.o.b): In function `svn_delta_make_editor':
/usr/src/subversion16/subversion-1.6.17-3-msys-src/subversion-1.6.17/subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c:785: undefined reference to `_svn_delta_default_editor'
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o _Core.dll -Wl,--out-implib=lib_Core.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s core.o /usr/lib/perl5/5.8.8/msys/CORE/libperl.dll.a -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/bindings/swig/perl/libsvn_swig_perl/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_client/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_delta/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_repos/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_wc/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_diff/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_subr/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_local/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_svn/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_ra_neon/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_util/.libs -L/usr/src/subversion16/subversion-1.6.17-3-msys-src/bld/subversion/libsvn_fs_fs/.libs -lsvn_client-1 -lsvn_delta-1 -lsvn_fs-1 -lsvn_ra-1 -lsvn_repos-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_subr-1 -lsvn_fs_util-1 -lsvn_swig_perl-1 -lapr-1 -lintl -lz -laprutil-1 -lexpat -lperl -L/lib/perl5/5.8.8/msys/CORE
My question already answer by other post. Its the linker order issue. Check the answer below:
Linker order
I just need to move around the linker for svn_swig_perl to link it before svn_delta to solve the problem.

How to link during Matlab's MEX compilation

I've written a program of the following form:
#include "stuff_I_need.h"
int main(){
construct_array(); // uses OpenMP pragma's
print_array();
return(0);
}
that compiles, links, and runs correctly with the following command:
`gcc44 -I/home/matteson/sundials/include/ main.c -lm -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial -fopenmp -o /home/matteson/MPI_test/CVODE_test/main_test`
"gcc44" is simply gcc version 4.4 and is named like this because it's being compiled on a cluster that maintains several versions of gcc. The libraries sundials_cvode and sundials_nvecserial are used in the solving of several differential equations during the construction of the array.
Now when I want to transfer over to Matlab and try to compile the mex file of the form:
#include "stuff_I_need.h"
void mexFunction(int nlhs,mxArray* plhs[], int nrhs, const mxArray* prhs[]){
construct_array(); // uses OpenMP pragma's
print_array();
}
and try to compile with the following command in Matlab:
>> mex -v CC="gcc44" CFLAGS="\$CFLAGS -I/home/matteson/sundials/include/ -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial" mex_cvode.c
I get the following messages culminating in a link error:
-> mexopts.sh sourced from directory (DIR = $HOME/.matlab/$REL_VERSION)
FILE = /home/matteson/.matlab/R2010b/mexopts.sh
----------------------------------------------------------------
-> MATLAB = /misc/linux/64/opt/pkg/matlab/R2010b
-> CC = gcc44
-> CC flags:
CFLAGS = -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -L/home/matteson/sundials/lib -lsundials_nvecserial
CDEBUGFLAGS = -g
COPTIMFLAGS = -O -DNDEBUG
CLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
arguments = -DMX_COMPAT_32
-> CXX = g++
-> CXX flags:
CXXFLAGS = -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread
CXXDEBUGFLAGS = -g
CXXOPTIMFLAGS = -O -DNDEBUG
CXXLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm
arguments = -DMX_COMPAT_32
-> FC = g95
-> FC flags:
FFLAGS = -fexceptions -fPIC -fno-omit-frame-pointer
FDEBUGFLAGS = -g
FOPTIMFLAGS = -O
FLIBS = -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm
arguments = -DMX_COMPAT_32
-> LD = gcc44
-> Link flags:
LDFLAGS = -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmpofopenmp
LDDEBUGFLAGS = -g
LDOPTIMFLAGS = -O
LDEXTENSION = .mexa64
arguments =
-> LDCXX =
-> Link flags:
LDCXXFLAGS =
LDCXXDEBUGFLAGS =
LDCXXOPTIMFLAGS =
LDCXXEXTENSION =
arguments =
----------------------------------------------------------------
Warning: You are using gcc version "4.4.4". The version
currently supported with MEX is "4.3.4".
For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release/
-> gcc44 -c -I/misc/linux/64/opt/pkg/matlab/R2010b/extern/include -I/misc/linux/64/opt/pkg/matlab/R2010b/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -L/home/matteson/sundials/lib -lsundials_nvecserial -DMX_COMPAT_32 -O -DNDEBUG "mex_cvode.c"
-> gcc44 -O -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmpofopenmp -o "mex_cvode.mexa64" mex_cvode.o -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
mex_cvode.o: In function `mexFunction':
mex_cvode.c:(.text+0x2b2): undefined reference to `N_VNew_Serial'
mex_cvode.c:(.text+0x2db): undefined reference to `N_VNew_Serial'
mex_cvode.c:(.text+0x35b): undefined reference to `CVodeCreate'
mex_cvode.c:(.text+0x39c): undefined reference to `CVodeInit'
mex_cvode.c:(.text+0x3dd): undefined reference to `CVodeSVtolerances'
mex_cvode.c:(.text+0x412): undefined reference to `CVodeSetUserData'
mex_cvode.c:(.text+0x449): undefined reference to `CVDense'
mex_cvode.c:(.text+0x482): undefined reference to `CVDlsSetDenseJacFn'
mex_cvode.c:(.text+0x50c): undefined reference to `CVode'
mex_cvode.c:(.text+0x5b4): undefined reference to `N_VDestroy_Serial'
mex_cvode.c:(.text+0x5c0): undefined reference to `N_VDestroy_Serial'
mex_cvode.c:(.text+0x5cc): undefined reference to `CVodeFree'
collect2: ld returned 1 exit status
mex: link of ' "mex_cvode.mexa64"' failed.
??? Error using ==> mex at 208
Unable to complete successfully.
Somehow, I'm not giving the correct flags to link appropriately. As I get the same set of errors (plus a few more) if I remove the commands to link in the gcc44 command, I'm pretty sure that I'm not getting the compiler to "see" the libraries.
My questions are :
If my analysis of the error is correct, what flags do I need to pass to the mex compilation command to successfully link?
Alternatively, what are the gcc flags to compile and link outside of the Matlab environment to compile a .mex64 executable?
If my analysis is wrong, where to go from here?
I think I've ruled out the unsupported compiler warning since I've been able to compile simple mex with OpenMP programs using gcc 4.4, but these did not have to link against anything except the math library. Also, if I compile with version gcc version 4.1.2 or 4.3.4 with or without the "-fopenmp" flags I get the same error.
In the end I do need version 4.4 because of certain OpenMP support that did not appear in prior versions.
Thanks in advance for the help.
--Andrew
Edits: (#KWATFORD)
So I tried the command with the statements outside the the quotes, and got the error:
-> gcc44 -c -I/home/matteson/sundials/include/ -I/misc/linux/64/opt/pkg/matlab/R2010b/extern/include -I/misc/linux/64/opt/pkg/matlab/R2010b/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -fopenmp -DMX_COMPAT_32 -O -DNDEBUG "mex_cvode.c"
-> gcc44 -O -pthread -shared -Wl,--version-script,/misc/linux/64/opt/pkg/matlab/R2010b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -fopenmp -o "mex_cvode.mexa64" mex_cvode.o -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial -Wl,-rpath-link,/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -L/misc/linux/64/opt/pkg/matlab/R2010b/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
/usr/bin/ld: /home/matteson/sundials/lib/libsundials_cvode.a(cvode.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/home/matteson/sundials/lib/libsundials_cvode.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
mex: link of ' "mex_cvode.mexa64"' failed.
??? Error using ==> mex at 208
Unable to complete successfully.
I'm a bit confused about the suggestion to recompile with "-fPIC" because when I look at the gcc44 command I see the -fPIC as an option.
Are they saying to recompile the library with -fPIC?
I don't have the source for the library, if the suggestion is to recompile the library is there a workaround?
What does "relocation against local object" mean?
My continued thanks.
Try not putting the -l, -L, or -I arguments in those environment variables. The mex function will handle those types of arguments directly. So perhaps something like:
mex -v CC="gcc44" CFLAGS="\$CFLAGS -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp" -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial mex_cvode.c
Kwatford put me on the right track with the second question. I was able to get the mex command to work by rebuilding the sundials solver with shared libraries. Specifically, I built with:
% make distclean
% ./configure --prefix=/home/matteson/sundials --enable-shared
% make
% make install
Also, thanks to kwatford for the fix to the original by calling:
mex -v CC="gcc44" CFLAGS="\$CFLAGS -fopenmp" LDFLAGS="\$LDFLAGS -fopenmp" -I/home/matteson/sundials/include/ -L/home/matteson/sundials/lib -lsundials_cvode -lsundials_nvecserial mex_cvode.c
since mex knows how to handle the -L and -I.
Matlab uses its own libstdc and libstdc++.
The shortcut would be to do a symbolink to those libraries to the gcc44 libraries that you want to use.
But this may not be the desired way to go. You could try compiling outside matlab prompt and see if it still fails compilation first.