When I try to compile a trivial example test.c
int main () {
return 0;
}
for a cortex m7 target with hard float ABI by using the following invocation
arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs test.c
I get this error:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: a.out uses VFP register arguments, /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a(lib_a-atexit.o) does not
[snip]
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libnosys.a(_exit.o)
collect2: error: ld returned 1 exit status
So the issue is that gcc is linking to the wrong libc.a. If I use the argument print-multi-directory, it would appear that my version of arm-none-eabi-gcc should support this architecture:
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs --print-multi-directory
thumb/v7e-m/fpv5/hard
And I can list the different versions of libc.a that are provided by arm-none-eabi-gcc:
$ find /usr/lib/arm-none-eabi/ -name libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/libc.a
/usr/lib/arm-none-eabi/newlib/armv6-m/libc.a
/usr/lib/arm-none-eabi/newlib/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/thumb/libc.a
/usr/lib/arm-none-eabi/newlib/armv7-m/libc.a
So it looks like there is a version of libc.a compiled for my desired architecture, but gcc isn't linking against it. How can I get gcc to link against the correct version of libc.a?
I'm using arm-none-eabi-gcc version 6.3.1 provided by the gcc-arm-none-eabi package for Ubuntu 18.04.
Related
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
core of stm32f10x should be cortex-m3,with the flag"-mcpu=cortex-m3" ↓(this is section of makefile ):
CFLAGS += -T$(STD_PERIPH_LIBS)/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO/STM3210B-EVAL/stm32_flash.ld
CFLAGS += -mlittle-endian -mthumb -mcpu=cortex-m3 -mthumb-interwork
CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
the error :
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: error: /tmp/ccwnNCUm.o uses VFP register arguments, t1.elf does not
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /tmp/ccwnNCUm.o
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: error: /tmp/ccaQhPT1.o uses VFP register arguments, t1.elf does not
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /tmp/ccaQhPT1.o
collect2: error: ld returned 1 exit status
Makefile:39: recipe for target 't1.elf' failed
make: *** [t1.elf] Error 1
but after replacing "-mcpu=cortex-m3" with "-mcpu=cortex-m4",the error disappears and the program runs normally.
this introduction of "st.com"
STM32F103 devices use the Cortex-M3 core, with a maximum CPU speed of
72 MHz.
so why is it "-mcpu=cortex-m4" instead of "-mcpu=cortex-m3"?
my arm-none-eabi-gcc:
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
Cortex-m3 doesn't have FPU option
I'm working on porting a windows project to linux so I am trying to learn/setup my build pipeline on linux(ubuntu). I use clang on windows and would like to use clang/llvm to compile my code on ubuntu but I am having an issue linking the c runtime library to my code. Here's an example of what I am trying to run just so I can set up the build scripts,
// -- system includes
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
// -- my includes
#include "crt.h"
int main() {
char title[] = "Text";
int title_length = strlen(title);
// -- sending string and length to platform dependent code
CreateBox(title, title_length);
return(0); }
After installing clang 3.4 on Ubuntu 14.04 LTS I run the above code as well as platform dependent code from the terminal,
clang++ -c main.cpp box_linux.cpp
The file compiles without error. Let's say I had I use the following command when trying to link,
ld main.o box.o
I get back the following error every single time,
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
In function 'main':
(.text+0x30): undefined reference to 'strlen'
I try linking libc++, libstdc++ but nothing seems to work. I am admittedly very, very new to linux and clang on linux so I apologize in advance. I have checked different questions here on stackoveflow as well as ubuntu's forums and LLVM's forums/docs to no avail. If anyone could point me in the right direction it would be greatly appreciated.
If you are using clang (or gcc) on linux you don't have to do the linking on your own. You can let clang do the linking for you and it will select the necessary libraries for your system just remove the -c flag form command line or use clang main.o. Clang understands that a .o file is already an object file and passes it on to the linker.
If you realy want to invoke ld on your own then start with clang++ -v main.cpp. The -v switch let clang print the invocation command for ld which e.g., looks like this:
/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -L/data/home/user/bin/../lib -L/lib -L/usr/lib /tmp/test-574b88.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
on my Ubuntu 14.04 LTS.
This is a follow-up to the question at Element-Wise Matrix Multiplication in Rcpp
I have been getting a number of different kinds of errors with RcppArmadillo since upgrading to Mavericks. I have Xcode 5.0.2 and Command Line Tools installed. Also, gfortran from Homebrew. But I keep encountering the error below --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b)
{ return(a % b); }", depends="RcppArmadillo")
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_18474.so] Error 1
clang++ -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I/usr/local/include - I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/3.0/Resources/library/RcppArmadillo/include" -fPIC "-mtune=native -g -O2 -Wall -pedantic -Wconversion" -c fileaf992bfb8f84.cpp -o fileaf992bfb8f84.o clang++ -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -L/usr/local/lib -o sourceCpp_18474.so fileaf992bfb8f84.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -lgfortran /Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/lib/libRcpp.a -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
Error in sourceCpp(code = code, env = env, rebuild = rebuild, showOutput = showOutput, :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
# Contents of Makevars
$ cat ~/.R/Makevars
CC=clang
CXX=clang++
CXXFLAGS="-mtune=native -g -O2 -Wall -pedantic -Wconversion"
FLIBS=-lgfortran
Commenting FLIBS=-lgfortran does not help and results in even more error messages --
> cppFunction("arma::mat schur(arma::mat& a, arma::mat& b) { return(a % b); }", depends="RcppArmadillo")
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/x86_64'
ld: warning: directory not found for option '-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_50381.so] Error 1
Thanks in advance.
Update
Following suggestions from response from Kevin and Dirk below, I re-installed Rcpp, RcppArmadillo and inline from source and updated FLIBS to point to the actual directory. This solved the issue.
# Update FLIBS in ~/.R/Makevars
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
#Re-Install from source
install.packages(c("Rcpp","RcppArmadillo","inline"),type="source")
#Restart R
EDIT: If you're a Homebrew user, you now instead need to use brew install gcc (gfortran is no longer provided separate of gcc), and you can then follow the instructions here to get set up.
You have to symlink the libraries to /usr/local/lib manually:
ln -s /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.* /usr/local/lib/
I thought brew link gfortran would handle this, but apparently it only symlinks the gfortran program and not the actual libraries. So, unfortunately, you have to do it yourself.
(Replace 4.8.2 with whichever version of gfortran you're using from homebrew.)
Alternatively, if you want to keep from modifying /usr/local/lib, you can use
FLIBS=-L/usr/local/Cellar/gfortran/4.8.2/gfortran
in your ~/.R/Makevars file instead, so R knows where to find the gfortran libraries.
I can only suggest you study the numerous threads on the r-sig-mac list, the different answers here on SO as well as the posts on the rcpp-devel list.
As your error comes from the failed Fortran linking, maybe also review the standard page by Simon U. as well as the tools page it points too. AFAIK you should use the (older) gfortran 4.2.* from that page with R -- but then I am not an OS X user.
Edit in late 2016: We now have more detailed instructions in section 2.16 of the Rcpp FAQ.
I need compile a piece of C code to be called from matlab (mex compiling).
I am doing that on an intel mac and, since I am using Matlab's R2010a (7.10.0.499), I'd like to compile the C code into a version for 64-bits.
For whatever reason, just doing mex with the -arch=maci64 option did not seem to work...
As a way around, I am compiling the C code to a mexmaci64 file directly on the command line.
I used the gcc calls made by mex (with the -v option on) as a starting point.
I managed to compile the C code to an object file, but it looks like I am not compiling the C code to the correct architecture.
Does anyone know how to correct the gcc calls below so the C code gets compiled to 64-bits intel macs?
Details are listed below.
As always, any help greatly appreciated...
Keep thirsty, my friends. :p
G
DETAILS:
Here is how I did the compilation and linking:
gcc -c -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -fexceptions -D MACVERSION -DMX_COMPAT_32 -O3 -DNDEBUG "BoxQP.c"
gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o "BoxQP.mexmaci64" BoxQP.o -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Here are the warnings I get:
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmx.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmex.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmat.dylib, file is not of required architecture
Ignoring the warnings and calling the BoxQP function from matlab results in the following error message:
??? Invalid MEX-file '/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64':
dlopen(/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64, 1): no suitable image found.
Did find: /Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64: mach-o, but wrong architecture.
PS: I tried changing the -DMX_COMPAT_32 flag to -DMX_COMPAT_64 but I do get the same warnings and same error...
PPS: I guess it may be relevant to mention that I am using Mac OS X 10.5.8 (the "tropical"/plain-vanilla Leopard, i.e., not the snow Leopard).
PPPS: The same happens with the yprime.c example provided by MATLAB