This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ELF_DYNAMIC_INTERPRETER changes for FreeBSD


   Date: Tue, 11 Apr 2000 23:44:03 -0700
   From: "David O'Brien" <obrien@FreeBSD.org>

   > I think this is the wrong approach anyhow.  Just use an appropriate
   > --dynamic-linker option when you link.  Even if you have a compiler
   > other than gcc, there must be some way to control the linker options.

   "there must be"... please lets talk real-world not ivory tower.  Unless
   we know that every compiler of every language has an option, the linker
   should specify the right ELF_DYNAMIC_INTERPRETER.  Not to mention this
   would be a new requirement for FreeBSD users.

Hmmm.  I thought I was talking real world.  Real world is that every
linker takes completely different options.  Even the most basic linker
options like -L and -l have different behaviour on different systems
in the presence of shared libraries.  A compiler which can't support
different linker options is totally nonportable and could, in fact, be
described as ivory tower.

   I'm trying very hard to make it so FreeBSD can use a stock Binutils.
   Please work with me on this.  I have the requirement that the linker use
   the right ELF_DYNAMIC_INTERPRETER w/o manual specification by users.  So
   how to engineer a solution?

People don't normally invoke the linker by hand, and when they do they
are responsible for knowing what they are doing.  I don't have too
much sympathy for that.  Adding the --dynamic-linker option is no
worse than knowing the precise sequence of startup and termination
object files to use.

In any case, there is only one way to engineer a solution, which is
what I already told you.  You must add a new FreeBSD specific BFD
target, and you must make the binutils configured for FreeBSD default
to using that target.  This will of course add a maintenance hassle
for the binutils maintainers and also for you and any other FreeBSD
developers who handle the binutils interface.  I would recommend
against doing it.  But there is quite simply no other way to
accomodate what you want to do.  It is a central assumption of BFD
that it support multiple targets simultaneously.  I will reject any
attempt to change that in the mainline sources.

There are a lot of people on this list and elsewhere who understand
how to work with ELF tools.  We've hammered out a lot of issues over
the years, including the specific one of how to make an ELF file
indicate which system it was built for.  The next time you want to
change the ELF specification, I encourage you to discuss it here
before inventing your own mechanism.

   This really sounds like the wrong answer to me.  In other words you want
   the GNU ld to be *broken* on FreeBSD such that people have to use a very
   long and cumberson option to make it work correctly??  I don't think so.
   Would you be taking this same stance if Solaris used some other name for
   the dynamic linker?

That's a tough question to answer in some ways, since Solaris to a
considerable extent sets the standard for SPARC ELF.  If Solaris did
something differently, we would probably consider that to be standard
and be doing that anyhow.

Perhaps you will consider another answer.  GNU/Linux on i386 requires
the long and cumbersome --dynamic-linker option in order to generate
working executables.  For reasons not worth going into here, the i386
GNU/Linux developers chose not to follow the standard set by UnixWare.
However, GNU ld does follow the standard set by UnixWare and specified
in the i386 ELF processor supplement.  We have forced GNU/Linux to
adapt (not that that was difficult, since they were willing to play by
the standard rules anyhow).  If you run GNU ld on an i386 GNU/Linux
system, and you do not specify the --dynamic-linker option, the
resulting executable will not run.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]