I'm having a hard time understanding the output of ldd - Especially the processor identifiers.
The string in question is this one:
Shortest.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, from ']', not stripped
I have several questions about it:
What does "ELF" mean? I know that's what Linux binaries are called like (Windows Binaries are called PE Binaries, "Portable Executable" Binaries), but isn't ELF an abbreviation for something?
What does LSB mean? I can't even guess it...
I see the string "Intel" there, now I seriously wonder about the portability of Linux binaries, as ldd seems to expect every binary to be compiled on a intel processor... but what if it wasn't compiled on a Intel processor? Or when I attempt to run the binary on a computer that doesn't run ontop of a Intel processor?
Why the ']'? My guess is it should be some sort of Linker identify, but ']' doesn't look much like a Identifier...
Thanks in advance
ELF is executable and Linkable Format - it specifies the format of the library - see Executable and Linkable Format. LSB specifies the endianness of the data. The Intel 386 means it will run on all chips compatible with the 386, which includes Pentiums, and AMD's chips, but not (say) Power PC or IBM/370 architectures.
As for the ']', this library wouldn't have anything to do with the test utility, would it? The one that allows you to say:
if test -x foobar
or
if [ -x foobar ]
in shell scripts.
ELF
LSB
Intel: Linux binaries are not meant to be portable
accros CPUs and achitectures. This one is meant to be used on a CUP able
to run Intel 80386 birary code.
']': ??
Related
Basically I'm trying to run eclipse's 64bit linux installer on a 64 bit linux machine, but it's giving me an exec format error. All other solutions I've seen say it's usually an error with it not being the right processor speed.
My question is twofold. 1) What is going on here? 2) How do I properly download and install Eclipse?
I'm running linux through chromebook
Here is the output of a few command line statements
uname#loc:~/Desktop/eclipse-installer$ ./eclipse-inst
-bash: ./eclipse-inst: cannot execute binary file: Exec format error
uname#loc:~/Desktop/eclipse-installer$ file eclipse-inst
eclipse-inst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b621fbc20e80d7ac375ece11a5775fc6686b71c7, with debug_info, not stripped
uname#loc:~/Desktop/eclipse-installer$ uname -m
aarch64
To answer your first question I think this could help:
You are trying to execute a program designed to run on a "x86_64" based processor using a processor designed based on "aarch64" architecture. These are two distinct architectures although they both may be using 64-bits for addressing and so forth, but it's not the matter of the bits. They are two completely different CPU designs.
For your second question I can not help because I don't use Eclipse.
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 am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp
Short question: how can I reliably distinguish between mips, mipsel, mips64 and mips64el on any linux distribution?
Longer explanation:
We provide statically built/distribution independent binaries (for TeX) for many architectures. Installation script usually runs uname -s and uname -m to determine operating system and architecture. Binaries are then fetched from server based on that decision, so it needs to works reliably. And it does. Almost everywhere except for Mac OS X 10.6 and Debian. Mac would report i386 on OS that runs 64-bit applications, while Debian reports mips64 for 32-bit OS.
Debian on mips64 correctly reports processor type, but that doesn't help me for at least two reasons:
OS is 32-bit, not 64-bit as the name might suggest.
It is running in little-endian mode. Debian calls that mipsel, not mips. It can often be switched, but OS only runs in one mode and mips software is often incompatible with mipsel.
Here are some outputs from system commands:
$ file my_binary_name
my_binary_name: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped
$ dpkg-architecture
DEB_BUILD_ARCH=mipsel
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=mipsel
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=mipsel
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=mipsel-linux-gnu
DEB_HOST_ARCH=mipsel
...
dpkg-architecture would be perfect for the task, except that it is not present on other Linux distributions.
The first problem was already addressed here: How to determine whether a given Linux is 32 bit or 64 bit?
The command
getconf LONG_BIT
properly reports 32 on my system.
But how do I determine whether it is big endian or little endian?
I figured out that config.guess can determine the difference, but it does so by running the compiler which may not be present on end user's computer. On top of that config.guess completely ignores the fact that operating system works in 32-bit mode and wrongly reports mips64el instead of mipsel.
The file command tells you:
$ file my_binary_name
my_binary_name: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped
The LSB there stands for least-significant byte, meaning little endian. The output of file given a big-endian binary will be MSB, most-significant byte.
Note that MIPS has 3 ABIs (actually more), one of which is n32. n32 has native 64-bit integers but only 32-bit pointers (and requires a 64-bit kernel).
For n32 binaries file will still report 32-bit:
ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV)
o32 (what debian uses):
ELF 32-bit LSB executable, MIPS, MIPS-III version 1 (SYSV)
n64:
ELF 64-bit LSB executable, MIPS, MIPS-III version 1 (SYSV)
lscpu should work.
For example:
# lscpu
Architecture: mips
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
I realise this is an old question, but it's unanswered so here goes.
You already know the bit size, so surely you can check:
case "$var" in
mips64el | mipsel) endian=little;;
mips64 | mips) endian=big;; # or: echo big;; if you need to capture it
(where $var holds your string as given: note you can pattern-match in case; see:
the POSIX sh documentation.)
If not, you should be able to test for a define from autoconf; use the MIPSEL macro.
Trying to run my program in FreeBSD OS, I have the following results:
$ ./myprogram
ELF binary type "0" not known
./myprogram: 1: Syntax error: "&" unexpected (expecting ")")
$ file myprogram
myprogram: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
not stripped
The program is built In GCC on Ubuntu computer. What can I do? Can I build the program for FreeBSD on my Ubuntu computer by changing some build options, or I need to build it in FreeBSD OS? Maybe there is some way to convert executable to format recognized by FreeBSD?
You can run a lot of Linux programs on FreeBSD, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html.
If this doesn't work, the easiest solution would be to recompile your program on FreeBSD.
2021-06-21: This answer is outdated. As of 2021, FreeBSD includes Linux® binary compatibility, which will run most Linux binaries, save for those which "overly use i386™ specific calls, as enabling virtual 8086 mode".
A large number of Linux programs can be compiled on BSD systems however they are not the same operating system. Linux and BSD are technically not binary compatible.
These days BSD ships with an ABI (Application Binary Interface) for Linux which will translate Linux sys-calls on the fly (Much how WINE operates). This will allow you to run Linux ELF binaries on BSD systems with a small performance penalty.
That being said, they are not the same operating system and your best bet would be to compile for the target system either by gaining access to it or using a method of cross compiling.
Try branding the executable as a linux executable using brandelf (you still need all the dependent libraries setup though, or try linking it statically
http://www.freebsd.org/cgi/man.cgi?query=brandelf&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html
brandelf -t "Linux" and it should work.