I am working on link a pre-build shared library. I found my .so file is 64 bits and file information is shown below
li#cleanerSaddy:/usr/local/lib$ file libspd.so.3.0.0
libspd.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0x1148c741ed5bf3568abd82ec33187b9cf9117cf5, not stripped
when I run ndk-build, it gave me "incomabpatible target". shown below
li#cleanerSaddy:~/Projects/spd-viewer-on-android$ ndk-build
[x86] Install : libspdio.so => libs/x86/libspdio.so
[x86] SharedLibrary : libhello-jni.so
/home/li/Android/adt-bundle-linux-x86_64-20131030/android-ndk-r9b/toolchains/x86-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/bin/ld: error: ./obj/local/x86/libspdio.so: incompatible target
collect2: ld returned 1 exit status
make: *** [obj/local/x86/libhello-jni.so] Error 1
Here is my ABI APP_ABI := x86.
So, how do I solve this problem in order to compile that third party library successfully?
No Android system is 64 bit, your library should be compiled in 32 bits, preferably with Android NDK tool chain.
Related
I'm trying to execute a 32 bits binary, that is my scenario:
Host compiled: Kali (64 bits)
Host executed: Debian 7 (32 bits)
Host compiled is the machine where I'm compiled to 32 bits the .c
Host executed is the machine where I'm executing the 32 bits binary
I have the package gcc-multipart installed and compiled using this command: gcc -m32 binary.c -o program -pthread
File Result:
program: ELF 32 bits LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2
When a try to execute in Debian, this error ocurrs /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.33' not found`
I'm looking for some solutions, try to re-install/upgrade the libc6, but did not work.
I'm trying to compile a large codebase written for a 32 bit embedded processor to run on a 64 bit desktop processor for simulation/unit testing. I need the resulting object to be a shared library. This is not an issue in Windows, I can build a dll like this (/DWIN32) and it runs fine.
In Linux, I'm able to compile and link with the -m32 option given to both gcc and the linker and get a shared library out. The problem is, this library is (just like I specified with -m32) a 32 bit library and will not run on my 64 bit arch. With Python, I try to load the library (using ctypes.cdll.LoadLibrary())
OSError: out.so: wrong ELF class: ELFCLASS32
I discovered the -mx32 option, and according to the docs this is exactly what I want:
The -mx32 option sets int, long, and pointer types to 32 bits, and
generates code for the x86-64 architecture.
So, I pass -mx32 to the compiler and the linker (replacing my -m32 option) and get the following (snipped the output):
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: cannot find -lm
I get the same results with gcc 4.7 and gcc 4.8. The above output is from gcc 4.8.
I have gcc-4.8-multilib and g++-4.8-multilib installed.
My library path is:
LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:/usr/lib/gcc/x86_64-linux-gnu/4.8/32:/usr/lib/gcc/x86_64-linux-gnu/4.8/
From .bashrc I've specified it like this (below), in despair adding the /4.8/ and /4.8/32/ stuff after reading that the linker would only bind with the libraries that work.
export LIBRARY_PATH=/usr/lib/$(gcc -print-multiarch):/usr/lib/gcc/x86_64-linux-gnu/4.8/32:/usr/lib/gcc/x86_64-linux-gnu/4.8/
As I mention, this works quite well already on Windows as a dll, I have to believe I'm just missing something. Pointers should be 32 bits and longs should be 32 bits, the whole thing should run on x86_64. -mx32 says it will do exactly that (right?).
Checking one of the objects after compiling in -m32:
$:~/project$ file foo.o
foo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
And checking the same object after compiling with -mx32:
$:~/project$ file foo.o
foo.o: ELF 32-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Am I going about this the wrong way? Can I still use my 32-bit shared library with some sort of compatibility layer?
I saw a bug report against gcc 4.7 regarding these link errors... But I didn't see much conclusion from it. This page says that gcc 4.8 is the recommended minimum for x32, so I installed it. Still -- I can't get it to link. -m32 links fine.
-m32 is normal 32-bit mode, and yes most x86-64 GNU/Linux systems have multiarch support with 32-bit libraries that you can install if not already installed.
The -mx32 option is not what you want at all. It compiles code for the x32 ABI, which uses 32-bit addresses with 64-bit registers and instructions. The resulting code is not compatible with 32-bit processors (as it uses 64-bit instructions), but is also not compatible with 64-bit code (which will use 64-bit addresses). So everything in user-space has to be compiled with it in mind, including libc, and even the kernel needs to support x32 user-space and syscalls: https://unix.stackexchange.com/questions/121424/linux-and-x32-abi-how-to-use (i.e. just like supporting 32-bit binaries, x32 is effectively a separate architecture.)
Complicating matters further, the testing you've been doing on Windows hasn't been doing what you think at all. Passing /DWIN32 to the Visual C++ compiler only defines a macro called WIN32 (like -DWIN32 would for GCC); it doesn't make the compiler generate 32-bit binaries. 64-bit Windows executables cannot load 32-bit libraries; the libraries you've been testing with have actually been 64-bit.
If you want to unit-test 32-bit code, you'll need to test it on a fully 32-bit target architecture like -m32. x32 is not such a system. (32-bit code under a 64-bit kernel is fine, though, unless you're worried about only having 2G or 3GiB of address-space usable by user-space in your embedded system, instead of 4GiB under a 64-bit kernel.)
Your initial error, trying to load the library you successfully built, indicates that you are NOT using a 32-bit version of Python, so it can't build the 32-bit shared library.
If you install an i386 (32-bit) version of Python it should be able to load the library. What's more, that is the version of Python you'll need to run on your embedded i386 target.
Note that all the above assumes your "32bit embedded processor" is i386 compatible. If its not (its an ARM or MIPS or some other 32bit embedded processor instead), you'll need to install cross compilers for that target to build your library and an emulator (such as QEMU) to run executables.
I have freshly installed Fedora 19 x86_64 on my PC.
I wrote a simple OpenGL program, but failed to compile it.
gcc -o quad quad.c -lX11 -lGL -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../.. /../libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /lib/libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
I have MesaGL and other libraries in place (i.e. /usr/lib) then what's wrong ?
For me, something was wrong with the library symlinks:
$ locate libGL.so | egrep ^/usr | xargs file
/usr/lib/libGL.so: symbolic link to `/usr/lib/libGL.so.1'
/usr/lib/libGL.so.1: symbolic link to `/usr/lib/libGL.so.1.2'
/usr/lib/libGL.so.1.2: symbolic link to `/usr/lib/fglrx/fglrx-libGL.so.1.2'
/usr/lib/fglrx/fglrx-libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib64/FGL.renamed.libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=46121ec8b16424a8b65a0cf11c3f9730ae0e49f5, stripped
/usr/lib64/libGL.so: broken symbolic link to `libGL.so.1.2.0'
/usr/lib64/libGL.so.1: symbolic link to `/usr/lib64/libGL.so.1.2'
/usr/lib64/libGL.so.1.2: symbolic link to `/usr/lib64/fglrx/fglrx-libGL.so.1.2'
/usr/lib64/fglrx/fglrx-libGL.so.1.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
So /usr/lib/libGL.so pointed at a 32-bit lib and /usr/lib/libGL.so was a broken link. I fixed the /usr/lib64 version to point correctly at libGL.so.1 (and the /usr/lib version to point at the 64 bit version for good measure) and this seems to have gotten my code compiling.
There are warnings about incompatible versions of libGL, and also about incompatible GCC libraries. I think you might have a 32 bit version of gcc installed on a 64-bit OS. Try
file -L `which gcc`
to check on this.
The problem is fixed.
I removed ATI Catalyst Driver v13.6 beta by executing "aticonfig --uninstall"
REBOOT
compile the program with same commands, and it was success :)
Now I reinstalled ATI Catalyst Drivers v13.6 beta
REBOOT and compile the program again,
It builds SUCCESSFULLY !!
Don't know what was wrong, but I have OpenGL working now :)
Install freeglut-devel :
# sudo yum install freeglut-devel
I need to link AMD acml library in a C++ project.
I tried to compile it in this way:
g++ mainConsole.cpp -L./acml/pgi64_int64/lib -lacml
but I get this error:
/usr/bin/ld: skipping incompatible ./acml/pgi64_int64/lib/libacml.so when searching for -lacml
/usr/bin/ld: skipping incompatible ./acml/pgi64_int64/lib/libacml.a when searching for -lacml
/usr/bin/ld: cannot find -lacml
What can I do in order to solve?
It seems the linker was told to use a 64 library when the compilation was done using 32 bits.
Your call to g++ will both compile and link. It's easier to debug if you split both. For example:
g++ -I./acml/pgi64_int64/include mainConsole.cpp -o mainConsole.o
g++ -L./acml/pgi64_int64/lib -lacml mainConsole.o -o mainConsole
You can verify the library using file. On my system I get:
$ file /usr/lib/acml/gfortran/libacml.so
/usr/lib/acml/gfortran/libacml.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
The compiled object should be the same:
$ file mainConsole.o
mainConsole.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
The problem is either 32 bits compilation of your own project, or more probably your use of the "int64" verison of ACML. You can read more on int64 here. I suggest you try with the non-int64 version of ACML. For example, instead of downloading acml-5-3-1-pgi-64bit-int64.tgz, download acml-5-3-1-pgi-64bit.tgz.
I am using a shared library. Which I am using it to cross compile my executable. During the linking stage linker throws the error file format not recognised.
When I run ld on it libcclass.so: file not recognized: File format not recognized
When I run file libcclass.so: it gives libcclass.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), not stripped
If you're cross-compiling an executable, you also need to cross-compile all of the shared libraries it depends on, and link against those. For example, you can't link an i386 executable to an x86_64 shared library.