ld's --enable-new-dtags shortcomings

[Jan Beulich]

Hello,

while generally I would favor using this option for any new code (and
convert old code to use it, too), and while I would even consider
reasonable this being the linker's default, there are problems with
doing so. Since DT_RPATH and DT_RUNPATH functionality is substantially
different, DT_RUNPATH's presence hides DT_RPATH's, and DT_RUNPATH does
not permit specifying a path to use for dlopen() calls from the binary,
it may not be desirable or even possible to have a binary carry a
DT_RUNPATH tag. However, --enable-new-dtags only collectively enables
all of the new tags (with the sole exception of DF_STATIC_TLS which is
handled specially). This is particularly problematic if I need a binary
to have the DF_ORIGIN flag set (note that DF_1_ORIGIN may not do for
compatibility reasons since DT_FLAGS_1 is not a gABI tag, even though
interestingly it hasn't been living in the OS-specific range for more
than 4 years) but maintain the DT_RPATH search characteristics.

As an additional note - the DT_HIOS definition seems to be wrong: gABI
specifies 0x6FFFF000, glibc also uses this value, but binutils says
0x6FFF0000.

Thank you,