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
Related
I am compiled my assembly files with nasm:
nasm -felf32 test.nasm -o test.o
I've done it on 64 bit OS. Now, I would like to link it with:
My OS is Ubuntu.
gcc -m32 test.o -o test
but I cannot because I have not installed 32-bit libraries.
I know that I should install 32bit libraries and it is a solution. But, I cannot install because I am not root. Can I solve that problem in another way? For example, to use ld and download need *.so files from the Internet?
I use Ubuntu 15.10 64 bit. gcc-5-multilib, g++-5-multilib, libc6-i386, kernel headers and all build toolchain are installed. When I try to compile 32 bit library (for linux) like:
gcc -m32 -fPIC -shared -Wl,-soname,mylib.so -o mylib.so mylib.c
I get an error:
/usr/include/bits/socket.h:345:24: fatal error: asm/socket.h: No such file or directory
What can I do to compile a code with #include <sys/socket.h> on 64 bit for 32 bit linux?
You need to provide the path of asm. Just check the path and link like this. Depending on system path may vary. Most of the time downloading gcc-multilib solve this issue.
$cd /usr/include
$sudo ln -s asm-generic/ asm
OR
$cd /usr/include
$sudo ln -s x86_64-linux-gnu/asm asm
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
I am trying to compile a plugin for Stata (a statistical programming language) that is written in C. Its author was able to compile it on other machines using the following commands on a 32-bit PC Windows (using Cygwin):
gcc -shared -mno-cygwin stplugin.c strgroup.c -O3 -funroll-loops -o strgroup.PC.Windows.plugin
He was also able to compile it on 64-bit Unix with:
gcc -shared -fPIC -DSYSTEM=OPUNIX stplugin.c strgroup.c -O3 -funroll-loops -o "strgroup.PC (64-bit x86-64).Unix.plugin"
And Macintosh OS X with:
gcc -bundle -arch i386 -arch x86_64 -arch ppc -DSYSTEM=APPLEMAC stplugin.c strgroup.c -O3 -funroll-loops -o "strgroup.Macintosh.MacOSX.plugin"
I am trying to compile it on 64-bit Windows 7 machine using Cygwin 1.7.9-1 and gcc v4.5.3. The mno-cygwin flag is giving me trouble, but I am not able to figure out how to use a mingw-targeted cross-compiler.
The -mno-cygwin option is no longer supported.
Install either of the mingw-*, mingw64-i686-* or mingw64-x86_64-* toolchain (category Devel in the Cygwin package manager) to get a proper cross-compiler.
When I compile a simple Hello World! program that uses the sscanf function on my local Debian lenny x64, it works. But when I upload the same program to the server running CentOS x86, it will not work. If I do not use sscanf, then the program works on both computers.
gcc -std=c99 -O2 -pipe -m32
If I compile it with sscanf but without -std=c99, then it works on both computers.
gcc -O2 -pipe -m32
What is the problem with sscanf and c99 on CentOS x86 ? I thought that compiling with the -m32 flag would work on all Linuxes ? (I have limited access to the CentOS server, so I do not have access to error messages.)
Probably the CentOS box is using an old version of glibc. Since the nonstandard GNU extensions to their scanf implementation ended up making glibc conflict with c99, they added a nasty hack of redirecting *scanf to __isoc99_*scanf when -std=c99 is in use; if your copy of glibc is missing the __isoc99_sscanf symbol, the program will then fail to run.
Static linking, or linking to a different libc without ugly backwardsness-compatibility hacks, would solve the problem.
Are you uploading the binary or the source and then recompiling? If you are uploading the binary, you are probably running into a library compatibility issue between Debian and CentOS.
If that is the case, upload the source only and recompile on CentOS.
If you do not have permission to compile # CentOS, then try compiling a static binary. You can use dietlibc which makes smaller binaries than glibc or try EGLIBC which is the default C library that Debian will use starting Debian "squeeze".
I came up with the similar problem, it works # Ubuntu 64-bit, but the compile fails # CenseOS 64-bit (REHL5 desktop):
the error message is:
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
when i copied the executable file compiled #Ubuntu to REHL5, and run it another error appeared:
elf file os abi invalid
it is compiled without flag -std=c99, i'm a newbie at C, and looking forword some workarounds, ex. add some flag.
Makefile:
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO
You need to update your glibc to 2.7
download the rpm package from here:
http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
needs:
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
command:
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm