I am trying to get a basic cross compiler for the BeagleBone Black setup.
I tried to follow this tutorial but ran into some snags...
When dowloading the toolchain for the arm platform the tutorial showed the "gcc-arm-linux-gnueabi" as a package for Ubunto so I figutred there would be one for Debian... No dice, the closest I could find is the "arm-none-eabi" package. Being new to this I gave it a shot.
I made a simpe "Hello World" application as the tutorial suggested and it compiles under the standard tools. Under the cross tools however, I add the prefix amr-none-eabi- and the path /usr/bin/ the following is the result of the build.
make all
Building file: ../src/test.cpp
Invoking: Cross G++ Compiler
arm-none-eabi-g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP MF"src/test.d" -MT"src/test.d" -o "src/test.o" "../src/test.cpp"
Finished building: ../src/test.cpp
Building target: test
Invoking: Cross G++ Linker
arm-none-eabi-g++ -o "test" ./src/test.o
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/exit.c:70: undefined reference to `_exit'
makefile:45: recipe for target 'test' failed
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-abort.o): In function `abort':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-openr.o): In function `_open_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/openr.c:59: undefined reference to `_open'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/sbrkr.c:58: undefined reference to `_sbrk'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-signalr.o): In function `_kill_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-signalr.o): In function `_getpid_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/writer.c:58: undefined reference to `_write'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/closer.c:53: undefined reference to `_close'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/readr.c:58: undefined reference to `_read'
collect2: error: ld returned 1 exit status
make: *** [test] Error 1
18:18:55 Build Finished (took 564ms)`
I can't seem to find anyhting that works to remove these errors. I would greatly appreciate any guidence I can get on this. I'm using Debian 8.1.0 and it is up to date.
I figured this out and my mistake was to use the wrong toolchain...
Linaro makes a toolchain for the hard float arm architecture.
Simply get the linked archive, extract it, and point eclipse in the right direction. I've now got eclipse to proerly build programs for the beaglebone. I've also got eclipse to properly connect to the remote application on the BBB.
Cheers,
I am using Mac OSX (yosemite V 10.10.1) and running MATLAB 2014a on it.
I wanted to use SPAM library (sparse modeling software by J. Mairal) on MATLAB and for that I have to install XCode6.1 (that has gcc). First I type in command window mex -setup and result is shown below:
mex -setup
MEX configured to use 'Xcode with Clang' for C language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html.
To choose a different language, select one from the following:
mex -setup C++
mex -setup FORTRAN
So after that I run the compile.m file in SPAM library and suddenly I saw an error that was:
add_flag =
-mmacosx-version-min=10.6
Warning: Directory already exists.
> In compile at 144
compilation of: -I./linalg/ -I./decomp/ -I./prox/ -I./dictLearn/ dictLearn/mex/mexArchetypalAnalysis.cpp
Building with 'Xcode Clang++'.
clang: warning: argument unused during compilation: '-fopenmp'
Error using mex
ld: warning: directory not found for option '-L/usr/lib/gcc/x86_64-linux-gnu/4.8/'
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in compile (line 439)
mex(args{:});
I don't understand what to do. please help me!
It appears that the actual error is occurring at the point of linking with precompiled libraries. The 2 issues are as follows:
The compile code apparently included in the compile.m file looks like it is intended to compile with gcc (it is trying to include files installed by GCC, possibly even linux-specific ones, are you sure that it's an OSX-compatible toolbox?), and yet the error strongly suggests that you are in fact using clang to compile it - you will either need to change the compiler (easy) or rewrite compile.m (not so easy).
One of the libraries that the code needs to have installed in order to be properly linked hasn't been found. On OSX I think this file should be called libgomp.dylib (any mac afficionados want to confirm this?). If you have it on your computer, then it's not in a directory that clang is looking in. You can confirm the library is installed by running find / | grep libgomp.dylib from the terminal - if it is there, you can add it into the compiler argument in compile.m using the -I /DIRECTORY_HOLDING_LIBRARY syntax.
It is entirely possible that fixing 1. will also remediate 2. - I have never tried using SPAM
I have tried to install the libsvm package with
mex -setup
(since "make" resulted in an error). This was followed by one choice for a compiler, so I chose "1".
Afterwards I typed in "make" got the following error though:
xcrun: error: SDK "macosx10.7" cannot be located
clang: warning: no such sysroot directory: '-mmacosx-version-min=10.7'
libsvmread.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
What can I do?
I think the following answer from the matlab support might be helpful (http://www.mathworks.com/matlabcentral/answers/103904-can-i-use-xcode-5-as-my-c-or-c-compiler-in-matlab-8-1-r2013a-or-matlab-8-2-r2013b):
The Mac OS X 10.7 SDK, available in Xcode 4.1 through 4.6, is used by
MEX and related capabilities. This SDK is no longer available in Xcode
5, resulting in errors similar to the following when compiling:
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or
in PATH
The simplest solution is to avoid updating Xcode to version 5 if you
are using R2013a or R2013b. If you need Xcode 5, or you have already
irreversibly upgraded to it, you can update MEX to use the 10.8 SDK:
In the MATLAB Command Window, execute the following commands:
cd(matlabroot)
cd bin
edit mexopts.sh
Save a backup copy of this file somewhere in case you make a mistake and you need to revert your changes.
Scroll down to the Mac (“maci64”) section of this file, beginning around line 120.
Replace all instances of 10.7 with 10.8; there are four of these in all (a fifth may be found in comments only)
Save the file, then execute the following command in the MATLAB Command Window:
mex -setup
Please note that this workaround links MEX files with a different SDK
than with which MATLAB was tested. Although there are no known
compatibility issues, support may be limited.
I am following this guide:
to get opencv to run on ubuntu 12.04 with eclipse juno CDT. But I get this error when I build all:
Building target: DisplayImage
Invoking: GCC C++ Linker
g++ -L/usr/local/lib -o "DisplayImage" ./src/DisplayImage.o -lopencv_core\ opencv_imgproc\ opencv_highgui
/usr/bin/ld: cannot find -lopencv_core opencv_imgproc opencv_highgui
collect2: ld returned 1 exit status
make: *** [DisplayImage] Error 1
In eclipse I have added:
opencv_core opencv_imgproc opencv_highgui
in the "Libraries (-l)" box. If I run (as described in the guide):
pkg-config --libs opencv
I get:
/usr/local/lib/libopencv_calib3d.so /usr/local/lib/libopencv_contrib.so /usr/local/lib/libopencv_core.so /usr/local/lib/libopencv_features2d.so /usr/local/lib/libopencv_flann.so /usr/local/lib/libopencv_gpu.so /usr/local/lib/libopencv_highgui.so /usr/local/lib/libopencv_imgproc.so /usr/local/lib/libopencv_legacy.so /usr/local/lib/libopencv_ml.so /usr/local/lib/libopencv_nonfree.so /usr/local/lib/libopencv_objdetect.so /usr/local/lib/libopencv_photo.so /usr/local/lib/libopencv_stitching.so /usr/local/lib/libopencv_ts.so /usr/local/lib/libopencv_video.so /usr/local/lib/libopencv_videostab.so
so they seem to exists. But the names are a bit different compared to the guide. I have tried to change the includes in eclipse to:
libopencv_core.so libopencv_imgproc.so opencv_highgui
but that does not help. Any ideas?
EDIT:
This is how I setup the includes:
And this is how I setup the libs(linker):
Ah each lib must be on a separate line in the C++linker->Libraries box.
It seems that you forget to set Library search path(-L) to usr/local/lib/ in C++ Linker->Libraries:
Update: from your screenshot I see that all your libs are in one line. Take a look again at my screenshot.
Can anybody give me some hints for solving this?
I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:
mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);
This is the full command run by mex: (1)
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o "mxNiChangeDepthViewPoint.mexmaci64" mxNiChangeDepthViewPoint.o -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Then I'm getting the following error:
ld: library not found for -lOpenNI
collect2: ld returned 1 exit status
mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.
There is most definitely a file at /usr/lib/libOpenNI.dylib.
What kinds of things cause ld to throw this error?
What I tried:
I have tried creating a symlink called libOpenNI.so, like jmlopez suggested, no effect.
Could it be that libOpenNI is a 32bit library, and ld is not seeing it for that reason? Or would the error then be different?
Regarding the point above, it says that the build is "universal x86/x64"
Env vars:
I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.
setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);
In bash:
Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.
$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?
So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.
Did you trying adding OpenNi to your LIBRARY_PATH ?
export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi
First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.
Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.
BOOM! IT WORKS!
Okay, here it is:
The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)
So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:
cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/
And then changing this line (201):
LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
Removing the -Wl,-syslibroot,$SDKROOT argument.
Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:
mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);