I installed the latest release of Android Studio (2.2.2) on my Ubuntu 32 bits and I found that all the executable are compiled for a 64 bit architecture.
For example:
$>file aapt
aapt: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=b090905d7de6a44b1e136a3d8b819569a6d4f9cb, not stripped
Anybody knows if Android Studio is only released for 64 bit architectures or if there is a specific 32 bit installation link hidden somewhere?
32-bit OSes are not supported.
See the last message in the thread, posted by a Google member:
https://code.google.com/p/android/issues/detail?id=230623
In general we don't support 32-bit Linux distributions, see the "System Requirements" section on https://developer.android.com/studio/index.html.
Related
I have two ELF binaries on my Linux machine. When I run file on them I receive the following:
File#1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.0, not stripped
File#2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
Now as far as I understand it, the for GNU/Linux 2.2.X part stems from the .note.ABI-tag section of the binary and is added by the linker. The resulting value of 2.2.X depends on the version of the C library that is linked to the binary and describes the lowest ABI version that this C library version supports - meaning that File #1 will be supported on machines with a Linux kernel >= 2.2.0 and File #2 on machines with a Linux kernel >= 2.2.5. (Is that correct, or am I already wrong here?)
I would suppose that the differences in the ABI tag would stem from two different C library versions contained in the two binaries. But when I examine the strings of the binaries, both of them contain the string glibc 2.3.2.
How is this possible? It seems unreasonable to me, that a patch of some sort to the GNU C Library which didn't result in a version number change would change the supported ABI version...
The glibc ABI is supposed to be independent of the kernel version it is built for, and the test suite attempts to verify that a newly built glibc conforms to the official ABI.
The minimum kernel version required by a glibc release can be specified at glibc configure time, and this is what ends up in the .note.ABI-tag section. No patching of the glibc sources is needed. I'm not entirely sure whether it is correct that the configured minimum kernel version ends up in dynamically linked binaries (because it should be possible to run the binaries on older kernels with a differently built glibc).
However, for statically linked binaries, this is certainly correct because configuring a higher minimum kernel version will make the program fail to run on older kernels.
Can someone explain the difference between the three architectures?
Actually when I built a 64-bit application in Linux, I got a link error saying:
skipping incompatible library.a when searching for library.a
Then I used objdump -f on that library and I got the below output:
a.o: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
Does it mean the library is 32-bit? Is that the reason I am getting the linker error?
There are 3 common ABIs usable on standard Intel-compatible machines (not Itanium).
The classic 32-bit architecture, often called "x86" for short, which has triples like i[3-6]86-linux-gnu. Registers and pointers are both 32 bits.
The 64-bit extension originally from AMD, often called "amd64" for short, which has GNU triple of x86_64-linux-gnu. Registers and pointers are both 64 bits.
The new "x32" ABI, with a triple of x86_64-linux-gnux32. Registers are 64 bits, but pointers are only 32 bits, saving a lot of memory in pointer-heavy workflows. It also ensures all the other 64-bit only processor features are available.
Each of the above has its on system call interface, own ld.so, own complete set of libraries, etc. But it is possible to run all 3 on the same kernel.
On Linux, their loaders are:
% objdump -f /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2
/lib/ld-linux.so.2: file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000a90
/lib64/ld-linux-x86-64.so.2: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000000c90
/libx32/ld-linux-x32.so.2: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000960
Now, if you're getting the message about "skipping incompatible library", that means something is messed up with your configuration. Make sure you don't have bad variables in the environment or passed on the command line, or files installed outside of your package manager's control.
Beyond usual full 64bit and good old 32bit ABI there is a special ABI (inspired by SGI n32 envirnment) where pointers are 32bit (thus they are 32bit apps), but it is designed to run on 64bit host and have full access to all x64 goodies:
native x64 registers and math
more registers
SSE2/3/4, AVX1/2/...
Full 4Gb address space on 64bit host
It is called x32 ABI, link: https://en.wikipedia.org/wiki/X32_ABI
UPDATE
On Ubuntu system I have to install two packages (with deps) to get x32 working:
> sudo apt install gcc-multilib
> sudo apt install libx32stdc++-5-dev
Then compiling simlple C++ code with g++ -mx32 hellow.cpp works, making x32 executable
> file a.out
./a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0
I've installed ccx (Calculix solver programm) to solve a physical problem. The preprocessor cgx works fine, but when I run ccx with an .inp file (abaqus) in terminal, there comes an error:
ccx: symbol lookup error: ccx: undefined symbol: _gfortran_internal_malloc
when I only run ccx without a flag or .inp file, the result is:
Usage: CalculiX.exe -i jobname
I have libgfortran3 installed on my ubuntu 14.04 computer (64 bit: x86_64) and link the "libgfortran.so.3.0.0" file in "/usr/lib/x86_64/" with a created reference object file "libgfortran.so.2" (calculix needs that file 'cause the application runs on 32 bit). Without that reference file ccx doesn't work completely and thats why I had to link it. I use Calculix 2.8p2.
If your application is 32 bit, it needs 32 bit libraries to work. What you've done is install 64 bit libraries and then symlinked them to where the 32 bit library should be. This satisfies that the library "exists" but it will be unusable for the 32 bit program.
My library locations will differ from yours, but observe that they are different:
64 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
32 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
Secondly, if your program needs libgfortran.so.2, then symlinking a version of libfortran.so.3 in its place will not work. The change in library version number is a good signal that they are not compatible and not interchangeable. You will need to find a package that provides the older library for i386 architecture. This might mean installing a package from an older version of ubuntu.
I can not find any built versions of the binutils that could be pushed to an Android device an then be executed from there. The Android NDK toolchain provides them but in the wrong format.
Devices need them in ELF 32bit executable for ARM , but the toolchain only provides :
compiledtoolchain/bin$ file arm-linux-androideabi-objdump
arm-linux-androideabi-objdump: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
Does anyone know if and where to find objdump in a format so that it can be executed directly on an ARM android device ?
I haven't tried it on an Android device, but you might want to look at the pre-built binaries of my ELLCC cross compiler project: ftp://ellcc.org/pub (http://ellcc.org). Each tarball contains binaries for the clang/LLVM based C/C++ compiler, pre-built libraries, gdb, and the GNU binutils. All of the executables are statically linked so they don't rely on any shared libraries being available on the target system.
Let me explain.
I'm using webots in combination with aldebaran SDK. My operating system is Debian Squeeze amd64. Webots (64bit) will not work with aldebaran SDK because their libraries are compiled for 32bit. I do not have the source of the libs to recompile in 64bit.
While trying to compile the default nao controller under webots, i get the following error:
g++ -o naoqi_for_webots
naoqi_for_webots.o naoproxy.o
-L"/usr/local/webots/lib" -lController -L"/home/alex/naoqi-sdk-1.10.44-linux/lib"
-lnaoqiclient /usr/bin/ld: skipping incompatible
/home/vor73x/naoqi-sdk-1.10.44-linux/lib/libnaoqiclient.so
when searching for -lnaoqiclient
/usr/bin/ld: cannot find -lnaoqiclient
doing a
file libnaqoqiclient.so
tells me:
libnaoqiclient.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
The default project in webots has a Makefile which among other things has:
additional libraries:
LIBRARIES=-L"$(AL_DIR)/lib" -lnaoqiclient
I have downloaded and installed the 32bit version of webots, which links fine with the libnaoqiclient.so but will not link with other webots libraries (libController.so) where again, ld complains about incompatible type.
Can I link using webots 64bit with the 32bit aldebaran sdk ?
Can I link using webots 32bit with the 32bit aldebaran ? (I should, but I still get errors).
How can I specify to ld (or through Makefile even better) that the library is 32bits ?
Or in the case of using webots 32bit how can I specify that I want a 32bit binary ?
I do not care if my binary is 32 or 64bit, I do not care if I use the 32 or 64bit version of webots, all I want is to be able to compile the controllers.
Well, you can't mix and match 32-bit and 64-bit code. If you compile all your code using -m32 (to make it build as 32-bit), you may be able to get your application to link if you have 32-bit versions of all your libraries available.