I am not able compile my c program -m32 option even after installing the gcc-multilib. I am using Ubuntu x86_64 Virtual Machine on Windows. On use of
dpkg -l | grep gcc I see
ii gcc 4:7.4.0-1ubuntu2.3 amd64 GNU C compiler
ii gcc-11-base:amd64 11.1.0-1ubuntu1~18.04.1 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-7 7.5.0-3ubuntu1~18.04 amd64 GNU C compiler
ii gcc-7-base:amd64 7.5.0-3ubuntu1~18.04 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-7-multilib 7.5.0-3ubuntu1~18.04 amd64 GNU C compiler (multilib support)
ii gcc-8-base:amd64 8.4.0-1ubuntu1~18.04 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-9 9.4.0-1ubuntu1~18.04 amd64 GNU C compiler
ii gcc-9-base:amd64 9.4.0-1ubuntu1~18.04 amd64 GCC, the GNU Compiler Collection (base package)
ii gcc-multilib 4:7.4.0-1ubuntu2.3 amd64 GNU C compiler (multilib files)
ii lib32gcc-7-dev 7.5.0-3ubuntu1~18.04 amd64 GCC support library (32 bit development files)
ii lib32gcc-s1 11.1.0-1ubuntu1~18.04.1 amd64 GCC support library (32 bit Version)
ii lib32gcc1 1:11.1.0-1ubuntu1~18.04.1 amd64 GCC support library (dependency package, 32bit)
ii libgcc-7-dev:amd64 7.5.0-3ubuntu1~18.04 amd64 GCC support library (development files)
ii libgcc-9-dev:amd64 9.4.0-1ubuntu1~18.04 amd64 GCC support library (development files)
ii libgcc-s1:amd64 11.1.0-1ubuntu1~18.04.1 amd64 GCC support library
ii libgcc1 1:11.1.0-1ubuntu1~18.04.1 amd64 GCC support library (dependency package)
ii libx32gcc-7-dev 7.5.0-3ubuntu1~18.04 amd64 GCC support library (x32 development files)
ii libx32gcc-s1 11.1.0-1ubuntu1~18.04.1 amd64 GCC support library (x32)
ii libx32gcc1 1:11.1.0-1ubuntu1~18.04.1 amd64 GCC support library (x32)
I am seeing this error
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
As you use gcc-9 as implied by the error message you want to install the package gcc-9-multilib:
sudo apt-get install gcc-9-multilib
Related
I'm trying to compiled a C library using C make. I have three toolchain files:
MacOS arm64
MacOS x86_64
Linux x86_64
The files look like this:
# darwin.arm64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR arm64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
# darwin.x86_64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
# linux.x86_64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
My cmake invocation looks something like this: cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=${ROOT_DIR}/toolchains/linux.x86_64.toolchain.cmake .
The issue I'm having is that both the MacOS builds work correctly. The linux build, however fails with:
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - broken
CMake Error at /opt/homebrew/Cellar/cmake/3.25.0/share/cmake/Modules/CMakeTestCCompiler.cmake:70 (message):
The C compiler
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/maxgale/X/CMakeFiles/CMakeScratch/TryCompile-xBXBOz
Run Build Command(s):/usr/bin/make -f Makefile cmTC_8e560/fast && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_8e560.dir/build.make CMakeFiles/cmTC_8e560.dir/build
Building C object CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -MD -MT CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -c /Users/maxgale/X/CMakeFiles/CMakeScratch/TryCompile-xBXBOz/testCCompiler.c
Linking C executable cmTC_8e560
/opt/homebrew/Cellar/cmake/3.25.0/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8e560.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -o cmTC_8e560
ld: library not found for -lSystem
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_8e560] Error 1
make: *** [cmTC_8e560/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
What am I missing to get this cross-compile to working?
To me it seems you expect to build a MacOSX binary and expect it to run on a Linux distro. Let's start by a simple distinction between MacOSX and Linux-based operating systems:
MacOSX is Unix-based. For binaries it uses the "Mach-O" format.
Linux is Unix-like. For binaries it uses the ELF format.
Expecting to build a binary for linux without the proper toolchain is probably not going to work out well. I'm judging this by the fact that you are technically only setting "aesthetic" options in CMake. i.e.
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
These don't really do much. For example you need to configure the correct compiler, via e.g.:
set(CMAKE_C_COMPILER ... ) #This should point to a cross-compiler not your standard compiler
You also need to actually point to the correct libraries that the cross compiler should use. None of which you are doing.
As a side note: There is no -lSystem on linux. Most libraries (if not all) are lower-case.
So how do you fix this? Well the easiest way is to get a VM running with the linux kernel. Docker for desktop (on Mac) does this to provide you with docker containers. So if you already have that, you just need a docker container and build in it.
The last option you have is to check out something I found via a quick google search: osxcross on github. And even better (a docker image that handles everything for you): crossbuild on github
I have the most trivial program
$ cat helloworld.c
#include <stdio.h>
int main(void){
printf("Hello World!\n");
return 0;
}
$ gcc -g helloworld.c -o helloworld
Which I'm wanting to run under gdb
$ gdb -tui ./helloworld
When I run, from within gdb,
warning: the debug information found in "/lib64/ld-2.31.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
I think my system is up to date. I've already run
$ sudo apt-get update
$ sudo apt-get upgrade
I've attempted to reinstall any libc6* packages
$ apt list --installed | grep 'libc6'
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6-dbg/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
followed by, for each of those 7 packages, the equivalent of
$ sudo apt-get --reinstall install 'libc6-amd64'
but the warning is the same as previously.
Regarding ld-2.31.so, mentioned by #employedrussian in the comments
$ ls -lsh /lib64/ld-linux-x86-64.so.2
0 lrwxrwxrwx 1 root root 32 Dec 16 2020 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
$ ls -lsh /lib/x86_64-linux-gnu/ld-2.31.so
188K -rwxr-xr-x 1 root root 187K Dec 16 2020 /lib/x86_64-linux-gnu/ld-2.31.so
$ ls -lsh /lib64/ld-2.31.so
180K -rwxr-xr-x 1 root root 178K Dec 16 2020 /lib64/ld-2.31.so
$ dpkg -S /lib64/ld-linux-x86-64.so.2
libc6:amd64: /lib64/ld-linux-x86-64.so.2
$ dpkg -S /lib64/ld-2.31.so
libc6-amd64:i386: /lib64/ld-2.31.so
I've uninstalled libc6-dev-amd64 as identified by #employedrussian below
$ sudo apt-get purge libc6-dev-amd64
$ apt list --installed | grep libc6
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
libc6-dbg/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
libc6/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
But the exact same error reported in gdb remains
/lib64/ld-2.31.so is still present
$ cd /lib64
$ ls -l ld-2.31.so
-rwxr-xr-x 1 root root 182168 Dec 16 2020 ld-2.31.so
libc6-amd64:i386 is still installed
$ dpkg -l | grep libc6-amd64
ii libc6-amd64:i386 2.31-0ubuntu9.2 i386 GNU C Library: 64bit Shared libraries for AMD64
$ apt list --installed | grep libc6-amd64
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
Attempting to remove the package fails
$ sudo dpkg --remove libc6-amd64:i386
[sudo] password for rgh:
dpkg: dependency problems prevent removal of libc6-amd64:i386:
lib64tinfo6:i386 depends on libc6-amd64 (>= 2.16).
lib64ncursesw6:i386 depends on libc6-amd64 (>= 2.14).
lib64ncurses6:i386 depends on libc6-amd64 (>= 2.14).
dpkg: error processing package libc6-amd64:i386 (--remove):
dependency problems - not removing
Errors were encountered while processing:
libc6-amd64:i386
I do remember installing some ncurses packages a while back.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
This appears to be the root cause:
$ dpkg -S /lib64/ld-2.31.so
libc6-amd64:i386: /lib64/ld-2.31.so
According to this answer, libc6-amd64:i386 is a 64bit cross-compile tool-chain prepared for Ubuntu 32bit. Since you are on a 64-bit system, this package is useless.
Uninstalling it will likely fix your warning.
Update:
Trying to understand this
The format in which apt list and dpkg -l show package names is different. On my system:
dpkg-query -l libc6* | grep '^ii'
ii libc6:amd64 2.32-4 amd64 GNU C Library: Shared libraries
ii libc6:i386 2.32-4 i386 GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.32-4 amd64 GNU C Library: detached debugging symbols
ii libc6-dev:amd64 2.32-4 amd64 GNU C Library: Development Libraries and Header Files
ii libc6-dev-i386 2.32-4 amd64 GNU C Library: 32-bit development libraries for AMD64
ii libc6-dev-x32 2.32-4 amd64 GNU C Library: X32 ABI Development Libraries for AMD64
ii libc6-i386 2.32-4 amd64 GNU C Library: 32-bit shared libraries for AMD64
ii libc6-x32 2.32-4 amd64 GNU C Library: X32 ABI Shared libraries for AMD64
versus:
apt list --installed libc6*
libc6-dbg/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev-i386/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev-x32/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev/...,now 2.32-4 amd64 [installed,automatic]
libc6-i386/...,now 2.32-4 amd64 [installed,automatic]
libc6-x32/...,now 2.32-4 amd64 [installed,automatic]
libc6/...,now 2.32-4 amd64 [installed]
libc6/...,now 2.32-4 i386 [installed,automatic]
I believe the package you want to remove is this one:
libc6-dev-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
I've just upgraded to Xcode 5 beta with the April 15 2013 commandline tools and hit the following warning when running a cmake build during the standard CMakeTestCCompiler.cmake attempt to compile a simple test program:
cmake -version
cmake version 2.8.11.2
ld: building for MacOSX, but linking against dylib built for iOS Simulator file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/libSystem.dylib' for architecture i386
lipo -info /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/libSystem.dylib
Non-fat file: libSystem.dylib is architecture: i386
The compile step is:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -o /Users/temp/testCCompiler.c.o -c /Users/temp/testCCompiler.c
lipo -info /Users/temp/testCCompiler.c.o
Non-fat file: testCCompiler.c.o is architecture: i386
The link step is:
/usr/local/bin/cmake -E cmake_link_script /Users/temp/link.txt --verbose=1
where link.txt contains:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -Wl,-headerpad_max_install_names /Users/temp/testCCompiler.c.o -o testCCompiler
It seems that both testCCompiler.c.o and libSystem.dylib are i386, i386 is specified in link.txt, and i386 is the right architecture for the simulator so i'm not sure why it thinks it is building for MacOSX. Perhaps a commandline option is wrong :(.
thanks for any help!
The problem was that Xcode 5 replaces gcc with clang and adds in a "-triple" option that specifies OSX as the target. If you pass "-miphoneos-version-min=7.0" on both gcc command lines it works. You can see the clang command line if you pass "--verbose" to gcc. It's also necessary to add to the PATH for Xcode 5 so that cmake can find the necessary tools: export PATH=/Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode5-DP6.app/Contents/Developer/usr/bin:$PATH None of this is official.. but works for me so far.
run this comment on your client.app:
export PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:$PATH
Following the instructions given here, I’ve downloaded the latest version of OpenSSL (openssl-1.0.1e.tar.gz) from here and installed it on Ubuntu v12.10 (32-bit).
I have a C project in Eclipse CDT (v1.2.0.201212170456) that statically links to the following two .a files:
home/usr/local/ssl/lib/libcrypto.a
home/usr/local/ssl/lib/ libssl.a
However when I build my project I get these errors:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/ssl/lib/libssl.a when searching for -lssl
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find –lssl
My toolchain is CodeSourcery (Sourcery G++ Lite 2010q1-202) and is for 32-bit OS.
What am I doing wrong?
Compiler command line I'm using:
arm-none-linux-gnueabi-gcc -I"/path to my/include" -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
You have installed OpenSSL on an Ubuntu 32-bit machine (assuming x86), but are trying to link it to an ARM binary:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi: your ARM toolchain
/usr/local/ssl/lib/libssl.a: a 32-bit x86 version of OpenSSL
You will have to cross-compile OpenSSL for ARM using your ARM toolchain (i.e.: arm-none-linux-gnueabi-gcc), then you will be able to link it to an ARM binary.
It says that /usr/local/ssl/lib/libssl.a is not in the size expected. Try file on it to check if you compiled it in 32 or 64 bit version. And check how you are compiling your own program too. If both matches linker (ld) will link it fine.
If you compile your program into 64 bit and link it with libssl.a in 32 bit, this will not work
example:
file a.out
/* kind ofoutput */ a.out: Mach-O 64-bit executable x86_64
http://unixhelp.ed.ac.uk/CGI/man-cgi?file
I have gcc 4.1.2 installed. I installed a new separate gcc (version 4.4.6) too using yum on CentOS. Now my question is, do these two gcc versions use the same glibc version or glibc is different for both of them? How can I find out? Secondly, is it better to have a newer version of glibc in terms of performance?
Both GCC versions will use the glibc version you have installed on your system. GCC packages don't (usually) ship a separate C library.
Write a simple program which makes a call to a glibc function. Then compile it with both versions of gcc and then do ldd a.out on each compilation. You'll get the list of libraries used.
If your source file is test.c then:
$ gcc test.c -o out1 # with gcc 4.1.2
$ gcc test.c -o out2 # with gcc 4.4.6
$ ldd out1
$ ldd out2
This will show the libc versions used by each gcc.
Performance may or may not be better depending on the update done for glibc functions.