"Hello world!" binary links a bunch of unnecessary libraries

[taralx]

Looking at a simple println!("hello world") binary, I get these:

libdl (why?)
libpthread (I'm not using threads)
librt (why?)
libgcc_s (apparently for unwinding, despite my not using any dynamically linked crates)

[steveklabnik]

/cc @alexcrichton

[alexcrichton]

Hm I've wondered the same from time to time. We pass --as-needed to the linker so it auto-removes unneeded dependencies, but it's clearly not doing that! I've always suspected it doesn't actually do anything...

The answer is that if you use 100% of the standard library you'll need all these libraries, but you normally don't use the entire standard library as the unused portions are stripped out. It looks like the linker orders this as "strip unused dynamic libraries, then strip unused object code" rather than the other way around, meaning that when the "strip unused dylibs" pass comes along they're all actually in use.

Seems like an annoyance, but I'm not sure there's anything we can do about it or if it has any real impact beyond aesthetics.

[taralx]

No, they're all used.

libdl: dl_iterate_phdr
libpthread: many symbols
librt: clock_gettime
libgcc_s: _Unwind_Resume &c.

[alexcrichton]

It looks like they're used in terms of tools like nm -u, as in there's undefined references to symbols in those libraries. If you look at the actual object code (objdump -S), however, you notice the nothing from libraries like librt is used (e.g. clock_gettime are not mentioned in the executable).

It looks like libdl is used by libbacktrace which is in turn used for RUST_BACKTRACE, libpthread has to do with synchronization on backtraces and a few other places here and there, and libgcc_s is indeed used for unwinding and we just unconditionally link to the dynamic version.

[taralx]

Cool. My current task is to remove the libgcc_s dependency (for complicated internal reasons), so any advice on how that would be accomplished?

[taralx]

Any thoughts on something like function-sections to reduce the amount of unneeded code getting linked into the executable?

[alexcrichton]

Out of curiosity, what's the desire to remove libgcc_s? I don't know of any easy way off-hand to swap out that dependency for something else, although perhaps compiling everything with -Z no-landing-pads would cause us to not actually depend on it?

We actually do currently compile everything with function-sections and data-sections (which is why executables are as small as they are), but my comment above explains why this apparently doesn't strip out unused dynamic libraries.

[taralx]

No, they all appear to be used...

000000000000f106 <backtrace_initialize>:
...
    f1ca:       e8 c1 54 ff ff          callq  4690 <dl_iterate_phdr@plt> (libdl)

00000000000052b0 <__do_global_dtors_aux>:
...
    52ce:       e8 9d f2 ff ff          callq  4570 <__cxa_finalize@plt> (librt)

(Yeah, it's not clock_gettime -- must have been a script error.)

[taralx]

We don't have libgcc_s.so.1 deployed to our cloud systems because all of our binaries are supposed to be static-libgcc. Fixing that is... complicated, so I'm trying to find a way to avoid it here.

[alexcrichton]

Oh weird, we probably don't really need to link that in for librt, but oh well!

I forget if there's a technical reason for using libgcc_s instead of a static copy, but it may just be historical.

[taralx]

Should I open a separate feature request for static libgcc then?

[alexcrichton]

Sure! It looks like all the libs used in the initial report are indeed used, so I'm gonna close in favor of this to-be-opened issue. Thanks again for the report!