tools/elfutils: do not directly link gnulib to libelf
The compiled library resulting from importing gnulib has been
linked to libelf in order to easily cover other link dependencies.
However, this is not appropriate for linking libelf to other programs
as it bloats the resulting libelf library, and may result in
multiple defintions of symbols based on whether or not
certain modules from gnulib are included while elfutils
already has it's own definition of a function.
This is not a problem while building elfutils, because gnulib has
it's own way of creating function aliases and special declarations
that allow the linker to ignore the original function definitions,
however, when libelf is used to link to something else,
this results in an error at link time.
The gnulib manual recommended linking the libraries directly,
but those who have written it may not have considered how this
can affect the ability to link that library in other builds,
they likely assume the build targets would not be a dependency.
Fix this by removing the linking between gnulib and libelf
and instead overriding Make variables in order to add linking
between gnulib and each of the binaries provided by elfutils,
using Make functions to avoid applying it to other subdirectories.
The function tdestroy() would still be missing on macOS,
but the existence of the gnulib tsearch object having been built
is an indicator of whether or not it is needed
because it is only built conditionally by gnulib,
so include linking that object only when it exists.
Block the unnecessary replacement of some functions by gnulib
so that future linking with libelf doesn't require
the associated gnulib "rpl" prefixed functions.
These replacements are very strict in order to correct
minor bugs that don't have a real impact in almost all cases
or new standards requirements that are not yet in effect or used.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # macOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15368
Signed-off-by: Robert Marko <robimarko@gmail.com>