I was wondering if you could help me with some issues and questions I have for developing for the i.MX6 SoloX in bare-metal. I was looking at this link https://community.nxp.com/docs/DOC-106253 and downloaded the files there to use as an example of how to develop bare-metal c code for the i.MX6.
Then I setup my eclipse environment according to this tutorial https://community.nxp.com/docs/DOC-103736 but just the toolchain because I'm not interested in processor expert.
Since I'm working on Linux I didn't installed the Code Sourcery thing, instead I'm working with the gcc-arm-none-eabi which I installed using:
$ sudo apt-get install gcc-arm-none-eabi
And therefore I had to change the cs-rm and cs-make for rm and make respectively.
And I was able to create an eclipse project with the downloaded code and configure the project to make it work, nevertheless, I had the first error:
main.c:8:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make: *** [cortex_A9/main.o] Error 1
cortex_A9/subdir.mk:24: recipe for target 'cortex_A9/main.o' failed
And I was able to solve it adding "/usr/include" in the include directories at project > properties. But I'm not sure if this is a correct way of solving this error.
After fixing this error I got a new one:
syscalls.c:168:1: error: unknown type name 'caddr_t'
caddr_t _sbrk(int incr)
And for solving that I had to include explicitly the file "/usr/include/x86_64-linux-gnu/sys/types.h" and also I don't know if that is the correct way to solve it.
Now having eliminated those two errors I have the following one:
Building target: imx6-A9.elf
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-a9 -march=armv7-a -marm -mlittle-endian -mfloat-abi=softfp -mfpu=neon -mno-unaligned-access -fno-zero-initialized-in-bss -O0 -g -T "/home/mmalagon/iMX6/MX6SX_hello_MFG/cortex_A9/mx6slx.ld" -nostartfiles -Wl,-Map,"imx6-A9.map" -o "imx6-A9.elf" ./cortex_A9/main.o ./cortex_A9/syscalls.o ./cortex_A9/uart.o
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: cannot find -lg
makefile:42: recipe for target 'imx6-A9.elf' failed
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [imx6-A9.elf] Error 1
Which I haven't been able to resolve.
I don't know if this error is a consequence of the way I solved the two previous errors.
Does anybody know how to properly setup eclipse for i.MX6 bare-metal development?
Thank you very much for helping!!
If you want to develop bare-metal code for the i.MX6SoloX without using CodeSourcery then you need to execute this:
sudo apt-get install gcc-arm-none-eabi libnewlib-arm-none-eabi -y
And then choose "Custom (arm-none-eabi-gcc)" at Project>Settings>C/C++ Build in the 'Toolchains' tab.
Related
Using -fsanitizer while compiling programs helps in finding location of memory leaks easily. But how to use this with vscode.
I only know that for compiling a program in vscode through terminal we need to type in g++ file_name.cpp -o executable_name.exe and for running .\program_name
Adding -fsanitizer to this command as an argument does not work for me. How to compile your program using fsanitizer on vscode?
Edit: I have been trying to use it as
g++ -std=c++17 -O2 -Wall -fsanitize=address
tempCodeRunnerFile.cpp -o tempcodeRunnerfile.exe
But this keeps giving me some kind of error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lasan: No such file or directory
collect2.exe: error: ld returned 1 exit status
This is unrelated to VSCode. The problem is your platform - MinGW traditionally has poor sanitizer support.
Your MSYS2 environment, MINGW64, only supports UBSAN (with stripped-down error reporting, compile with -fsanitize=undefined -fsanitize-undefined-trap-on-error).
There's also CLANG64 environment, which does have ASAN. Install its Clang (pacman -S mingw-w64-clang-x86_64-clang), and compile using clang++ located at C:\msys64\clang64\bin. If you're compiling from MSYS2 terminal, make sure you start the right one: launch it with clang64.exe, or the "MSYS2 Clang x64" shortcut (I don't remember the exact name).
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I am able to cross compile hello world program in raspberry pi from my Ubuntu 14.04 PC through eclipse. But I am not able to cross compile opencv programs. I am getting following error:
15:19:20 ** Incremental Build of configuration Debug for project MyFirstRaspProg **
make all
Building target: MyFirstRaspProg
Invoking: Cross G++ Linker
arm-linux-gnueabi-g++ -L/home/tvsm/raspberry -L/usr/lib/gcc-cross/arm-linux-gnueabi/4.7 -L/usr/lib/i386-linux-gnu/lib -L/usr/arm-linux-gnueabi/lib -o "MyFirstRaspProg" ./src/MyFirstRaspProg.o -lopencv_highgui
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: cannot find -lopencv_highgui
collect2: error: ld returned 1 exit status
make: * [MyFirstRaspProg] Error 1
15:19:20 Build Finished (took 56ms)
Can anyone help how to resolve this?
The error is because you have specified arm-linux-gnueabi-g++ to refer a library, which is not available. So you need to cross compile the necessary library for ARM platform and link it during build.
Follow the below link to cross compile the opencv on Ubuntu machine.
http://www.ridgesolutions.ie/index.php/2013/05/24/building-cross-compiling-opencv-for-linux-arm/
You will be left with an "install" folder at the end of the process.
In eclipse specify the library path and include path to "lib" & "include" folders in the "install" folder respectively.
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);