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.
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.
I'm working with a Target board which use micro controller MCIMX6DP6AVT8AA - i.MX 6 series 32-bit MPU, Dual ARM Cortex-A9 core, 850MHz, FCBGA 624
(refer http://www.nxp.com/webapp/search.partparamdetail.framework?PART_NUMBER=MCIMX6DP6AVT8AA). My board run Linux kernel 3.1.1
I use cross-compile toolchain arm-poky-linux-gnueabi, run on host Ubuntu14.04 to build a Application for Target board. After built successful, i checked the output file as below
~$ file MyApp
MyApp: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1,
BuildID[sha1]=a800b4033343517d3368a3f3ca0c87eb98f6c1ba, not stripped
But when i run it on Target board, there was error
~$ ./MyApp
-sh: ./MyApp: No such file or directory
I don't know what i did wrong ?
The message is very likely coming from the dynamic linker. Look at the output of:
ldd MyApp
It will tell you all the library dependencies and where they are found on the system. Install those which hadn't been found.
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.
I am trying to cross compile the ipsectools(ipsec-tools-0.8.2) downloaded from opensource for the mips architecture.
I downloaded ipsectools from : https://sourceforge.net/projects/ipsec-tools/
and applied a patch as mentioned in : https://dev.openwrt.org/browser/packages/net/ipsec-tools/patches/006-linux-3.7-compat.patch?rev=35312
Susequently after extracting and applying patch, i used the following commands,
./bootstrap
autoconf
./configure --enable-security-context=no CXX=${CROSS_COMPILE}g++ CC=${CROSS_COMPILE}gcc AS=${CROSS_COMPILE}as AR=${CROSS_COMPILE}ar LD=${CROSS_COMPILE}ld NM=${CROSS_COMPILE}nm OBJCOPY=${CROSS_COMPILE}objcopy OBJDUMP=${CROSS_COMPILE}objdump RANLIB=${CROSS_COMPILE}ranlib READELF=${CROSS_COMPILE}readelf STRIP=${CROSS_COMPILE}strip --host=mips-wrs-linux-gnu --build=i586-wrs-linux-gnu
Now if i crosscompile for mips architecture it compiles successfully for mips. But the racoon binary file created shows following
[samb#bhlinv09 racoon]$ file racoon
racoon: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with unknown capability 0x410000000f676e75 = 0x1000000070403, not stripped
Can anyone tell me what is this "unknown capability error"?
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.