This is the mail archive of the
mailing list for the binutils project.
Re: i386-pc-nto-qnx patch
- From: jtc at acorntoolworks dot com (J.T. Conklin)
- To: "Graeme Peterson" <gp at qnx dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 25 Apr 2002 23:40:09 -0700
- Subject: Re: i386-pc-nto-qnx patch
- References: <200204251559.LAA58388520@node128.ott.qnx.com>
- Reply-to: jtc at acorntoolworks dot com
"Graeme Peterson" <email@example.com> writes:
> It seems to me that it is six of one, half a dozen of the other as to
> whether this gets done in gcc or binutils. My preference is gcc,
> because we need to have a QNX specific specs file anyway, this is
> how we already do it, and this limits the number of QNX specific
> changes that need to be rolled in and maintained in binutils.
> Who makes this decision? There are two conflicting patch submissions,
> both of which work, but not together.
I'm not sure there is a conflict. My gcc port supports both QNX 6.0
and 6.1, which requires the linker to know the correct interpreter.
You have separate gcc configs for the different versions of the OS, so
the same binutils config can be used. Your gcc would presumably work
with mine, as the --dynamic-linker passed via the specs would override
the compiled in default, but my gcc port would fail.
Even though 6.0 and 6.1 are similar enough to have a common gcc config
now (assuming that ld will use the correct interpreter), I wouldn't be
surprised if some future release required separate configs. Given that
likelyhood, I can't think of a reason to let the aesthetics of a single
gcc config make the decision.
Additionally, it is unlikely that anyone is going to be using the
linker directly to create an executable. Anyone who does is going to
have to know all the details of which and in what order startup files
have to be specified. Requiring users to specify the interpreter is
not going to be a significant burden.
Having the config specify the interpreter appropriate to the specific
version of the OS does no harm, but it's benefit is slight now and is
questionable in the future (future OS releases may require separate
gcc configs anyway). Given this, I don't think there is a compelling
reason for me to submit this change.
There still is a conflict in the ports though, as mine still pulls out
generic QNX definitions into it's own emulparams .sh file which are
inherited by an x86 port specific .sh file; while Graeme's has it all
in one. If need be, I could submit this change again if his port goes