I 'm newbie.(And I cannot speak English better.)
I'm trying compile Nim code using gtk
{.push header:"<gtk/gtk.h>",varargs.}
proc gtk_init(argc,argv:pointer=nil)
proc gtk_window_new(typ:int):pointer
proc gtk_main_quit
proc gtk_widget_show(win:pointer)
proc gtk_main
{.pop.}
var maindow:pointer
gtk_init()
maindow=gtk_window_new(0)
maindow.gtk_widget_set_size_request(300,200)
maindow.gtk_widget_show()
gtk_main()
I'm using this command ->
nim c -r test
However,It couldn't succeed.
fatal error: gtk/gtk.h: No such file or directory
#include <gtk/gtk.h>
^~~~~~~~~~~
compilation terminated.
I already installed libgtk-3-dev ,but didn't solved the problem.
(so I don't know that syntax of the code is correct.)
What should I do for compile it?
When you use GTK from a C program, you have to pass the correct include directories with -I and the correct linked libraries with -l. Usually, these are obtained by calling pkg-config:
$ pkg-config --cflags gtk+-3.0
-pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
$ pkg-config --libs gtk+-3.0
-lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
Thus, to tell Nim to pass the right flags to the C compiler and linker, you can do the following:
{.passc: staticExec("pkg-config --cflags gtk+-3.0").}
{.passl: staticExec("pkg-config --libs gtk+-3.0").}
{.push header:"<gtk/gtk.h>",varargs.}
proc gtk_init(argc,argv:pointer=nil)
proc gtk_window_new(typ:int):pointer
proc gtk_main_quit
proc gtk_widget_show(win:pointer)
proc gtk_main
{.pop.}
var maindow:pointer
gtk_init()
...
Such usage of GTK wouldn't be very typical though. You may find it easeir to just use an existing wrapper such as nim-gtk3.
Related
I'm working with STM32CubeIDE using gcc compiler. In the build output I have to search for warnings and errors in a hundred lines of compiler-output infos. I'm explicitly interested in all warnings and errors! But I do not need something like this as there isn't any warning or error:
(Useful information)
arm-none-eabi-gcc "../gmem/wdog.c"
(followed by 912 useless bytes)
-mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DNUCLEO -DUSE_HAL_DRIVER -DSTM32F446xx -DUSE_FULL_LL_DRIVER -c -I"E:/STM32CubeIDE_11/fatl22_lcd/Ampel" -I../Core/Inc -I"E:/STM32CubeIDE_11/fatl22_lcd/lcd" -I"E:/STM32CubeIDE_11/fatl22_lcd/rtc" -I"E:/STM32CubeIDE_11/fatl22_lcd/so" -I"E:/STM32CubeIDE_11/fatl22_lcd/uart" -I"E:/STM32CubeIDE_11/fatl22_lcd/interrupts" -I"E:/STM32CubeIDE_11/fatl22_lcd/gmem" -I../Drivers/STM32F4xx_HAL_Driver/Inc -I"E:/STM32CubeIDE_11/fatl22_lcd/debugpins" -I"E:/STM32CubeIDE_11/fatl22_lcd/funk" -I"E:/STM32CubeIDE_11/fatl22_lcd/kabel" -I"E:/STM32CubeIDE_11/fatl22_lcd/scheduler" -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -Wconversion -fstack-usage -MMD -MP -MF"gmem/wdog.d" -MT"gmem/wdog.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "gmem/wdog.o"
How can I get rid of this crap ?
I searched for gcc option help files and some "how to increase verbosity" hoping to find the contrary ;-) .
I found explicit help for reducing warnings, which is not my intention.
I'm trying to compile a gtk program on PowerShell so that I can use pkg-config's output as input to gcc but gcc is taking the whole output as a single command line option and return the error:
gcc.exe: error: unrecognized command line option '-mms-bitfields
-pthread -mms-bitfields -IC:/gtk/include/gtk-3.0 -IC tk/include/cairo -IC:/gtk/include -IC:/gtk/include/pango-1.0 -IC:/gtk/include/atk-1.0 -IC:/gtk/include/cairo -IC:/gtk clude/pixman-1 -IC:/gtk/include -IC:/msys/opt/include -IC:/msys/opt/include/freetype2 -IC:/msys/opt/include -IC:/msys t/include/libpng16 -IC:/gtk/include -IC:/gtk/include/freetype2 -IC:/gtk/include -IC:/gtk/include/libpng16 -IC:/gtk/in de/gdk-pixbuf-2.0 -IC:/gtk/include/libpng16 -IC:/gtk/include/glib-2.0 -IC:/gtk/lib/glib-2.0/include -LC:/gtk/lib -lgt -lgdk-3 -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lz -lpangowin32-1.0 -lp ocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl'
the command line I'm using:
gcc hello.c -o hello $(pkg-config.exe --cflags --libs gtk+-3.0)
I've also tried:
$(gcc hello.c -o hello $(pkg-config.exe --cflags --libs gtk+-3.0))
either return same result. How do I fix this?
It seems that pkg-config.exe --cflags --libs gtk+-3.0 command return its output as single line and thus in PowerShell it is parsed as single string object. And when string with spaces (actual rule more complex and version dependent) passed to native application, then PowerShell tries to be helpful and add quotes, so it be interpreted as single argument. One way to prevent it is to use '--%' "operator":
gcc hello.c -o hello '--%' $(pkg-config.exe --cflags --libs gtk+-3.0)
Note that it is not actually --% operator, so it not make rest of the line to be interpreted literally. Actually it is just string with value --%.
The "magic" happens because when PowerShell command line builder for native applications encounter --% string it disables automatic quoting for arguments with spaces for any remaining arguments. And it also passes them thru [Environment]::ExpandEnvironmentVariables to resolve environment variables in %VariableName% form.
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.
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.
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.