Yocto prelink status

[Adhemerval Zanella]

Hi Nicolas,

Siddhesh told me to contact you since are involved on Yocto project.

Recent discussions on glibc maillist about prelink supported is leading
us to deprecate and remove its support on glibc.  Last year it was hinted
that Yocto seems to be maintained the project, although without much 
development [1].  

A recent issue [2] with a change to support llvm lld to build glibc lead
to a issue when prelink is used on the loader itself (which does not
make sense since kernel will be responsible and it does not really
care about prelink).

Finally the discussion on a recent patch proposal [3] to fix an issue
for sym dependency makes me believe that prelink is de facto deprecated,
since it does not work on most binaries in most architectures (20-30%
of the system is capable of prelinking according to Mark) and it tends
to get worse with new ABI extensions (for instance we plan to support
DT_RELR on 2.36 [4]).  For instance, prelink on a Ubuntu 20.10 on
x86_64 prelink -p shows that no binary could prelinked.

Mark also stated that for embedded prelinked still yields some gain
for loading time (specially for system boot) and memory consumption
(although I am not sure if it really yield any gain for recent
ABIs that avoid design such TEXTREL and writable PLT).

My plan is to remove prelink support for 2.35, at least to stir some
discussion.  Unfortunately I don't have a straightforward replacement,
I see prelink as very narrow solution that aims to fix some glibc design
drawnbacks (such as not being focused for static linking, neither to 
lower memory consumption). 

So I would to like if Yocto plan is to continue support prelink somewhat,
or if you have any other ideas.  At glibc side, we are trying to fix
some long-standing issues related to static linking (we deprecated
static dlopen, and we working on the NSS support), but it still required
some work to be on par with other static oriented libc.

[1] https://sourceware.org/pipermail/libc-alpha/2021-August/130404.html
[2] https://sourceware.org/pipermail/libc-alpha/2021-October/131989.html
[3] https://sourceware.org/pipermail/libc-alpha/2022-January/135189.html
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=27924