4
Example

When I run file on android-studio/bin/studio, I see:

android-studio/bin/studio: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b4be78977494d9024646ef0e45685a4152512800, for GNU/Linux 3.2.0, not stripped

The section of that which matters for this is "ELF" and "dynamically linked".

Question

Considering that it appears that statically linking an ELF is possible, would I describe this as a "dynamically linked executable", as opposed to the common "dynamically linked library"?

Rationale

I ask because I have to use "s on Google to see any matches (which could be Google being "helpful" by default), but even then, the results are from very niche locations. Perhaps that's expected, though? I'm asking for confirmation from someone who's familiar with this.

Improve this question
4
  • 1
    You should certainly never describe an executable, something which can be directly run from the command line, as a library, which cannot. Commented May 9 at 12:38
  • @PhilipKendall, can't a DLL be executable? I know that on Windows, the sole fundamental difference is a one-bit difference in a PE between a non-DLL executable and DLL is whether each's Characteristics field is set. Although DLLs expose tend to expose functions that an executable would not, I believe that both a PE and ELF can be executable in their own right, regardless. Commented May 9 at 16:11
  • 1
    Also, some libraries provide CLI to facilitate ccross-language use. Commented May 9 at 19:24
  • 1
    @PhilipKendall: You can make an ELF shared object (.so) that's usable as a library and also has its own _start entry point so is also executable. The fact that ELF supported that used to just be a silly computer trick, but was used as the basis for PIE executables to enable ASLR of static storage (.text/.rodata/.data/.bss). These days file knows to call it a PIE executable, but for years it would just say "shared object". It's still not normal for the same file to actually be used as a .so and an executable; the use-case would probably be for a library to have self-tests compiled in. Commented May 10 at 11:59

2 Answers 2

Reset to default
10

Yes, but only when you need to contrast it with statically-linked executables. Almost all Linux and Windows executables end up being dynamically linked.

From looking at https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

and https://github.com/file/file/blob/f77a1092e1862c2295a21077c9e28c2614a0eede/src/readelf.c

It looks like "dynamic" is printed if there is a dynamic link information ELF segment and "static" otherwise.

Improve this answer
3

When messing around with tiny hand-written assembly language programs, yeah it's 100% normal to say whether you're building a dynamically linked executable out of it or not. (Because a static executable is a very real possibility, so this is a special case of what @pjc50's answer mentioned.)

For example, in a dynamically linked executable, glibc's init hooks get called by the dynamic linker, so it's already initialized before execution reaches _start in the main program. So it can call printf even with a hand-written _start that doesn't call libc's init functions. (This is not something you should rely on for production use, but it is true on GNU/Linux. But not Cygwin glibc; I don't know why they don't take advantage of that.)

There's also ELF executable (ET_EXEC) vs. ELF PIE executable which is actually a "shared object", the same ELF type as a shared library. Most distros have configured GCC with -fPIE -pie as the default for several years now (https://stackoverflow.com/questions/43367427/32-bit-absolute-addresses-no-longer-allowed-in-x86-64-linux). Position Independent Executables (PIE) take advantage of the kernel and toolchain's support for an ELF shared object to be executable and have an INTERP field the same as an ELF executable (specifying a dynamic linker path, like how a text file can have a #!/bin/sh line specifying an interpreter.) Having an interpreter is what most people mean when they say "dynamically linked", even if there actually aren't any shared libraries that need to get linked.

file used to report PIE executables as "shared object" because that's what they were. They make ASLR possible, so that silly computer trick became a mainstream use-case. These days file identifies them as ELF 64-bit LSB pie executable (on my x86-64 desktop for example).

You can even have a static PIE, which ld and gcc won't create by default, only if you specify -static-pie, not -static -pie where -static overrides -pie.

Improve this answer
2
  • Why the 2 downvotes? The author obviously put some effort into answering, so constructive criticism would be useful. This is depressing to see. Commented May 10 at 15:08
  • 1
    @RokeJulianLockhart: Oh weird, yeah I don't get the downvotes either. I didn't put the most effort into this answer like formatting the links, and to some degree some of it could be a comment, but I still think overall it works as an answer. As someone who has personally used the phrase "dynamic executable" in Stack Overflow answers, I wanted to chime in here and shine some light on the low-level toolchain side of things. As long as you found it useful, I'd assume some other people did, too. Total vote count seems to be 0 up / 1 down at the moment. Commented May 10 at 18:57

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.