In the code for building applications for a vendor driver, I see the following directive:
SAMPLE_CFLAGS = -Wall -m32
I am not sure I quite understand what the option -m32 stands for?
I googled for the same and the closest I got was the following link, which refers to the flag -m64 but provides no description:
CPP/C++ Compiler Flags and Options
Can someone provide an explanation?
Related
I am utilizing yocto (dunfell) to cross-compile a project for multiple different architectures. Specifically, the targets I have are a 64-bit RaspberryPi4 (aarch64) and a 32-bit Orange Pi (armhf). My project that I am cross-compiling compiles and runs without issue when building for the raspi target; the runtime linker is properly set and things run without issue. However, whenever I build for the Orange Pi target, the program appears to compile without issue, but when I try to execute it on the platform, I get a "File not found" error.
This appears to be because the interpreter (runtime linker) is set to /usr/lib/ld.so which is not actually on the system. See below:
$ file my-exec
my-exec: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /usr/lib/ld.so.1, with debug_info, not stripped
In contrast, when I build the same program for the raspi target, the interpreter seems to be set properly for the system:
$ file my-exec
my-exec: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, with debug_info, not stripped
This issue seems to be isolated to just this project on the Orange Pi target. In comparison, other projects on the Orange Pi target look like the following and run without issue:
$ file other-exec
other-exec: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, stripped
What I am trying to understand is the following:
Which things could possibly be influencing the interpreter which is chosen at compile time? I have done some digging into this and nothing is explicitly set in my Makefile which could be causing this. Additionally, when I build a simple hello world application, the correct interpreter is chosen. It seems to be some set of flags in my compiling/linking which is causing this. Below is the compiling/linking output (I have excluded all the libraries it is also building which use the same arguments):
NOTE: make -j 24 i2c-core VERBOSE=1 CC=arm-poky-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot LD=arm-poky-linux-gnueabi-ld --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot
arm-poky-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot -I.. -I. -g -std=gnu99 -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wconversion -Wstrict-prototypes -DBUILD_CORE -c -o build/other.o ../other.c
...
arm-poky-linux-gnueabi-ld --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot build/my-exec.o build/other.o build/other1.o -luv -lsystemd -lc --entry main -o build/exe/my-exec
The linker which is being set (/usr/lib/ld.so.1) seems to be a really common linker to use, so why doesn't it actually end up on my system?
Am I fundamentally misunderstanding something about the ARM architecture which is resulting in this outcome? Are there different flags I could set at linking which would resolve this?
One further piece of information I have, which may or may not be relevant is the following:
An issue I hit while building for the Raspi target (showed up on both targets, actually) was the compiler wasn't able to find the entry symbol. This is quite a mature project and cross-compilers have been used to compile it, historically, but in a way that isn't yocto. This has never been an issue in the past. It wasn't until I added --entry main to the linker flags that this issue was resolved. I am wondering if there is a more fundamental problem which is resulting in these odd outcomes.
Thank you for any help you can provide on this. Please let me know if you have any additional questions about my environment.
After a few days of debugging, I figured out there problem. If anyone with more knowledge than I on linking would like to chime in to add things, please do. Ultimately, this was resolved by using gcc as the linker as opposed to using ld (the ones provided by yocto's cross compiler; i.e. aarch64-poky-linux-gcc).
In order to do this, I modified my recipe to pass in LD=${CC} LDFLAGS=${LDFLAGS} to my Makefile. Now, it builds and executes properly for both the RPi and OrangePi targets.
I believe this is mainly the case because the LDFLAGS provided by yocto actually can't be parsed by ld. From my research, it looks like ld is typically invoked by gcc. However, the flags still need to get to the complier. So, originally, LDFLAGS that needed to be passed into linking, weren't being passed in at all because I just assumed there was an error with doing it that way. So, be sure you're passing your LDFLAGS that yocto gives you into gcc.
I am currently compiling spec2000 art benchmark using following 2 flag settings:
-Ofast -m32 -march=native
-Ofast -m32 -march=native -fno-tree-vectorize
The second setting just disable the vectorizer. However, when I checked the objdump of the 2 settings, both of them shows some packed instructions like vmovapd, vxorpd, etc.
Can anyone provide some explanations? Thanks.
I am new to C++ compiling/linking.
I am trying to link all libraries statically with gcc, I tried using LDFLAGS=-static but did not work. Error message showed:
/bin/sh ./libtool --tag=CXX --mode=link /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib -o angora src/libangora.la -lblitz -lconfig++
libtool: link: /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -o angora -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib src/.libs/libangora.a -L/bgsys/drivers/V1R2M2/ppc64/comm/lib64 -L/bgsys/drivers/V1R2M2/ppc64/comm/lib -L/bgsys/drivers/V1R2M2/ppc64/spi/lib -lpthread -lm /home/dizhang/lib/blitz/lib/libblitz.a /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so /bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpich-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libopa-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpl-gcc.so /home/dizhang/lib/libconfig/lib/libconfig++.a /bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib
/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: attempted static link of dynamic object `/bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so'
collect2: ld returned 1 exit status
I did some search and found that, telling Makefile -Wl -Bstatic may solve this problem, but how exactly I should change this in my Makefile?
I tried searching -Wl in Makefile but it was not in the text.
Thanks,
Di
Looks like you are trying to build HDF5 with MPI support on BGQ.
As long as you end up passing a ".so" version of a lib to gcc on BGQ -- you will see this error. You may need to check how you are passing MPI info to HDF5's configure script.
In my case (building another project that uses CMake) passing BGQ's MPI compiler wrappers to CMake always created a problem where it would try to link MPI using the shared libs instead of the static ones. To resolve this, I had to make sure to explicitly specify the ".a" variants of the MPI libs.
I was using the options:
-O3
-march=armv7-a
-mtune=cortex-a8
-ftree-vectorize
-mfloat-abi=softfp
-fsigned-char
-Wall
-save-temps
for cross compiling for arm-v7 (32 bit) using ArmLinuxToolChain.
What is the equivalent compiler options for gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux to build for armv8? I tried using those same options with -march=armv8-a
-mtune=cortex-a53 and got:
aarch64-linux-gnu-g++: error: unrecognized command line option '-mfloat-abi=softfp'
The GCC options beginning with -m are machine-dependent options, so the availability of -m* options varies between targets. This is one such case. There is no soft float ABI defined for Aarch64, so GCC does not provide the ARM-specific -mfloat-abi option.
If you simply remove -mfloat-abi=softfp then your problem should be solved.
I would suggest you investigate whether you need -save-temps, which is normally only used for debugging or reporting compiler problems.
I've been trying to find the proper .a's and related flags for statically linking an app or SO under Linux. I know -static exists, but I can't use it as there's one specific SO I must link to.
To put it another way, I'm looking for the appropriate flags to statically link everything, except for a specific SO.
Thanks.
At my workplace we use -Bstatic and -Bdynamic but they are options to the linker ld. You can specify them with gcc using the -Wl option.
g++ -o app -Wl,-Bstatic -llib1 -llib2 -llib3 -Wl,-Bdynamic -llib4 app.o
Above shows command line for linking with lib1, lib2, and lib3 as static libraries and lib4 as a shared object library.