[sylware]

Don't forget to build 'correct' ELF64 binaries for broad elf(glibc)/linux distro support (-static-libgcc -static-libstdc++, and tight glibc ABI version control with binutils VERSION scripts).

At least those build options should be default.

[martz]

thanks for your comment, will look into it!

[sylware]

Let me add a bit more:

The part which in missed all the time is the control of the glibc ABI version. Either you link with an "old" glibc, or you go 'Right Way(TM)', documentation is on binutils web site (noscript/basic HTML) : https://sourceware.org/binutils/docs/ld/VERSION.html

Must include glibc internal symbols.

I would use the "readelf" command to audit the binaries for broad elf(glibc)/linux distro support (like stock unity has been). Namely DT_NEED entries, symbol/shared lib version requirement (at the end of readelf output), etc.

An additional note: in the case of a complex set of ELF64 binaries, don't forget that ELF DT_RPATH is deprecated in favor of ELF DT_RUNPATH (see man page of ld.so). To force DT_RPATH into DT_RUNPATH, you must use the follower binutils ld option: '--enable-new-dtags' (using the compiler driver, that would be '-Wl,--enable-new-dtags'. Carefull, you'll see that in ld.so man page, DT_RPATH and DT_RUNPATH do not behave the same way. You should use dynamic loading for your private shared libs using the $ORIGIN keyword anyway.

Ofc, dynamic loading (libdl/dlopen/dlsym/dlclose) is mandatory for system interface shared libs, and for core video games: libX11 set or xcb set of client X11 libs, libasound (wayland code is statically linked with its libxkbcommon for xkb keymap handling). Basically, The DT_NEED entries of your set of ELF64 binaries must reference only common glibc libs (and if you don't dynamically load them, your private ones with proper DT_RUNPATH).