Re: [PATCH] allow easier overriding of ELF_DYNAMIC_INTERPRETER

["David O'Brien" <obrien at FreeBSD dot org>]

On Sun, Feb 17, 2002 at 04:05:48AM -0500, Hans-Peter Nilsson wrote:
> > On Wed, Feb 13, 2002 at 08:35:47PM +0000, Nick Clifton wrote:
> > > > If so that still will not allow easy overriding of
> > > > ELF_DYNAMIC_INTERPRETER.  How about we just move that macro into its
> > > > own header?  It would be very easy to provide an alternate header
> > > > via ``configure''.
> > >
> > > OK - that seems reasonable.
> >
> > This is the basic patch I have to do this.  In general, does this look
> > OK?  Are there issues with the length of the header file names?
> 
> I don't like this.
> Why treat overrides of ELF_DYNAMIC_INTERPRETER specially?

The problem is the specified ELF_DYNAMIC_INTERPRETER is not correct for
90% of the Binutils installations.

It is an implementation detail that never should have been specified
psABI's.  So I desire an easy way to set the correct
ELF_DYNAMIC_INTERPRETER for the target.  Yes I know that GCC uses the
"-dynamic-linker" argument to `ld'.  And that one can manually specify it
when invoking `ld' directly.  However it is just wrong that `ld' on the
open source Unixes has the wrong ELF_DYNAMIC_INTERPRETER path.


> And when you actually do need to override stuff, what's
> wrong with the #ifndef approach: having a new file, defining
> stuff and including the original file, like is used in
> elf32-sh-lin.c?

Please explain how to use this approach.

On FreeBSD/sparc64 ELF_DYNAMIC_INTERPRETER should be
"/usr/libexec/ld-elf.so.1" (actually this is the case for all FreeBSD
systems).  How would make it so that where ELF_DYNAMIC_INTERPRETER is
used in elf64-sparc.c lines 1696-7, it would expand to
"/usr/libexec/ld-elf.so.1".

Doing this thru linker scripts, as I was told Solaris-x86 does, is ugly
and more convoluted.  It is just wrong having an incorrect path burned
into the binary.  Either all systems should use the linker script
"solution", or none should have to.


> Why add some new mechanism for generalization needlessly and for what
> seems a thought-up reason,

The need is real for open source OS's; and OS's that are not the vendor
of the hardware platform.

-- 
-- David  (obrien@FreeBSD.org)