I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
Related
I'm trying to compile a program that I've been able to compile on several other Debian environments with no issues using the C11 <threads.h> library on a relatively fresh install of Debian Bullseye with "gcc (Debian 10.2.1-6) 10.2.1 20210110" installed
with the command
gcc -o <progname> -O3 -Wall -Wextra -std=c11 -lpthread <sourcefile>
and I'm getting a string of linker errors in the form of
undefined reference to 'mtx_unlock'
as well as mtx_lock mtx_init thrd_create etc.
But I'm not getting an error saying the threads.h file is absent. I tried removing the -lpthread argument from the compilation command but this changed nothing.
What is going wrong?
The correct command line parameter seems to be -pthread without the l.
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.
Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)
I'm currently trying to compile a dynamically linked library (for a plugin system) using Windows and MinGW.
I compile each objects using this command line :
mingw-g++ -fPIC test.cpp
And the library using this line:
mingw-g++ -rdynamic -shared -Wl,-soname,test.so.1 -o test.so test.o
It doesn't work at all (using GCC with Linux, a similar line works though) : fPIC and rdynamic are ignored for some reason.
And while trying to make the library, it fails because the compiler try to link it with objects that are supposed to be resolved as I dynamically link it with the main binary.
So how do you compile this using MinGW?
Thanks :) !
-fPIC and -rdynamic are ignored because they are unused for Windows.
Also, .so is not the correct output extension for libraries on Windows.
To make a shared library for/on windows with GCC:
mingw-g++ -c file.cpp -o file.o
mingw-g++ -shared -Wl,--out-implib,libfile.a -o file.dll file.o
No more, no less.
And, documentation is always lovely to have: http://www.mingw.org/wiki/sampleDLL