[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ld's --enable-new-dtags shortcomings

From: Jan Beulich
Subject: ld's --enable-new-dtags shortcomings
Date: Fri, 05 Dec 2003 11:00:47 +0100


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

Thank you,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]