Hot answers tagged

33

Let's analyse the factors... Analysis: DEPENDENCIES ACCORDING TO PLATFORM: There are some issues that arise in an environment where developers are creating and maintaining several architecture-specific variants of an application: Different source code is required for different variants — Different UNIX-based operating systems may use different functions ...


32

Right from the man page you reference: elf - format of Executable and Linking Format (ELF) files ELF defines the binary format of executable files used by Linux. When you invoke an executable, the OS must know how to load the executable into memory properly, how to resolve dynamic library dependencies and then where to jump into the loaded executable to ...


28

There isn't a universal way, but you can make an educated guess by looking for things only done by one compiler. GCC is the easiest; it writes a .comment section that contains the GCC version string (the same string you get if you run gcc --version). I don't know if there's a way to display it with readelf, but with objdump it's: objdump -s --section ...


20

glibc has a configure option called --enable-kernel that lets you specify the minimum supported kernel version. When object files are linked with that glibc build, the linker adds a SHT_NOTE section to the resulting executable named .note.ABI-tag that includes that minimum kernel version. The exact format is defined in the LSB, and file knows to look for ...


15

I don't know if your version of sed will be binary-clean or if will choke on what it thinks are really long lines in its input, but barring those issues, editing the string in-place should work. To see whether it does, compare the old and new versions with cmp -l. It should tell you whether or not the only three differences between the two files are those 3 ...


12

How about: readelf -p .comment a.out


12

You can try using the strings command. It will create a lot of text output; by checking it you might guess the compiler. pubuntu@pubuntu:~$ strings -a a.out |grep -i gcc GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Here I know it's compiled with gcc but you can always redirect strings output to a file and examine it. There is one very good utility called peid ...


11

If you want to limit yourself to ELF detection, you can read the ELF header of /proc/$PID/exe yourself. It's quite trivial: if the 5th byte in the file is 1, it's a 32-bit binary. If it's 2, it's 64-bit. For added sanity checking: If the first 5 bytes are 0x7f, "ELF", 1: it's a 32 bit ELF binary. If the first 5 bytes are 0x7f, "ELF", 2: it's a 64 bit ELF ...


10

There is such a variety of platforms and software environments both *nix and other, that the software may be able to be run on, that allowing you to build an application (or library to use with applications) is the only realistic way to support as many combination of those components as a "good" software item does. Of course, licences such as the GPL ...


9

The following is a really good reference: http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/. It contains a bibliography at the end of a variety of different references at different levels. If you want to know every gory detail you can go straight to the source: http://www.akkadia.org/drepper/dsohowto.pdf. (Ulrich Drepper wrote the Linux ...


9

I think that /bin/true has to be the oldest working .. Well, can you call a zero-byte file a binary? touch /tmp/old_true chmod 755 /tmp/old_true /tmp/old_true echo $?


9

Bash knows nothing about ELF. It simply sees that you asked it to run an external program, so it passes the name you gave it as-is to execve(2). Knowledge of things like executable file formats, shebang lines, and execute permissions lives behind that syscall, in the kernel. (It is the same for other shells, though they may choose to use another function in ...


9

"Magic numbers" is the name given to constant sequences of bytes (usually) at the beginning of files, used to mark those files as being of a particular file format. They serve a similar purpose to file extensions. See the jargon file entry for more information. For example, PNG images always start with the same eight bytes: 137 80 78 71 13 10 26 10 Hence ...


8

A user generally encounters three types of ELF files—.o files, regular executables, and shared libraries. While all of these files serve different purposes, their internal structure files are quite similar. One universal concept among all different ELF file types (and also a.out and many other executable file formats) is the notion of a section. A section ...


8

You could check for references to function mcount (or possibly _mcount or __mcount according to Implementation of Profiling). This function is necessary for profiling to work, and should be absent for non-profiled binaries. Something like: $ readelf -s someprog | egrep "\s(_+)?mcount\b" && echo "Profiling is on for someprog" The above works on a ...


8

First, your question is based on a flawed premise. Programs are distributed in compiled format! The normal way to install software on Ubuntu, like on most other Linux distributions, and more generally on most Unix variants, is to install a package. On Ubuntu, you open the software center or some other package manager and browse the available software. When ...


7

This doesn't exactly answer your question, but... First of all, ELF is the specification use by Linux for executable files (programs), shared libraries, and also object files which are the intermediate files found when compiling software. Object files end in .o, shared libraries end with .so followed by zero or more digits separated by periods, and ...


7

No, it doesn't. It appears to mean that the version of libz you linked against when you compiled your program was built with different tools than the version on the madriva system you're using. The mandriva copy is missing symbol version info which was present in the copy of the libz library your program originally linked against. This has to do with ...


6

Like in the standard od command or hd, it means all the elided lines are the same as the preceding line. You can pass -v to make it display those lines anyway. From hexdump(1): The -v option causes hexdump to display all input data. Without the -v option, any number of groups of output lines, which would be identical to the immediately preceding group ...


5

Later edit: only this one does what jan needs: thank you huygens; find . -exec file {} \; | grep -i elf


5

Well of course it won't, because you won't have a C library anymore. All prelink does is to try and calculate an optimal load address for each library so that no program will have overlapping libraries, then update the libraries so that they default to loading at that address. Then when a program is run the libraries it uses are unlikely to need to be ...


5

There are few differences between ELF executables on different platforms. “UNIX - System V” is the common ground; System V is where the ELF format came from. The corresponding numerical value is 0. This value indicates that the executable doesn't use any OS-specific extension. Debian GNU/Linux, at least, configures GCC/binutils to generate executables with ...


5

In your ld.so.preload, you want to specify "$LIB" in your path rather than an explicit "lib" or "lib64". Thus, on a Redhat-style distro, "/usr/alternates/$LIB/libfoo.so" becomes "/usr/alternates/lib/libfoo.so" for a 32-bit process and "/usr/alternates/lib64/libfoo.so" for a 64-bit process. On an Debian-style distro, "/usr/alternates/$LIB/libfoo.so" becomes ...


5

Linux runs on more than just one particular CPU platform. If you distributed ELF files (or any other kind of raw executable), there'd be a chance that some versions of Linux couldn't run the software. In the spirit of making software as widely available as possible, using the source code is preferred. For example, Linux runs on Sparc, Intel, AMD, ARM, and ...


5

The original reason for distribution as source certainly was platform diversity; the Linux community has continued that methodology both for that and for new, partially political, reasons. Unlike e.g. Windows, Linux has historically never bothered to keep any ABI (application binary interface) stable across long periods of time - keeping the possibility to ...


4

You can also use this clever script that counts the numbers of various CPU instructions used by the binary. It is based on parsing objdump output. Beware that it can take quite a long time to finish if you use it on a big binary.


4

Look in /proc/$pid/maps. The address ranges are over 32-bit addresses (8 hexadecimal digits) or 64-bit addresses (16 hexadecimal digits). This works for any kind of executable, no matter what format. You can only get information about processes running as the same user (unless you're root). if ! [ -e /proc/$pid/maps ]; then echo No such process elif grep ...


4

In many cases (at least in the *nix world), the source code is the most portable version of the software. Having the source guarantees that the shared software will work on every platform that could possibly support it (which in many cases simply means POSIX-compliant). Releasing binaries only guarantees compatibility with platforms (both software and ...


3

You cannot. A program in binary form can only be executed in a machine with a compatible ISA (Instruction Set Architecture, see Wikipedia article). Intel maintains backward ISA compatibility in each processor generation as a newer ISA is always a superset of older ISA, and a program created for i386 will run on Pentium. However this is not the case between ...


3

I admit that the following isn't a great answer, but I believe the 0x8048000 value is enshrined in the ELF Specification. See figures A.4, A.5 and A.6 in that doc. The System V ABI Intel 386 Architecture Supplement also standardizes on 0x8048000. See page 3-22, Figue 3-25. 0x804800 is prescribed as the low text segment address/high stack address. And ...



Only top voted, non community-wiki answers of a minimum length are eligible