Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My gripe with linkers is: why can't they add the minimal metadata recording the actual paths of the shared libraries an executable or shared library was linked to. You can provide search paths to the linker with -L and LIBRARY_PATH and what not, but actually recording _what_ has been linked would be great for reproducibility. Right now you only have a DT_NEEDED entry with the soname of the lib, and at runtime this library has to be located... again.


Dynamic libraries are not linked at all, so the linker can't do that. The linker just records what shared objects the loader needs to find when the linked artifact itself is loaded, the path to those objects is therefore the responsibility of the loader to resolve and report.

On Linux you can find the shared libraries of a running process in /proc/<PID>/maps, or what libraries will be loaded when the executable runs/shared object is run in the current shell with ldd.


The location of DSOs on the build machine is rarely the same as on the target machine the software is run on, except for the corner case of building software locally on the target. Embedding detailed information about the build environment is rarely useful to anyone but those with malicious intent.


Vendoring dependencies and static linking everything lets you avoid a whole world of pain including the issue you ran into.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: