Re: incongruency in architecture mismatch linker warnings/errors

[Doug Evans <dje at transmeta dot com>]

Alan Modra writes:
 > On Mon, Jan 20, 2003 at 12:09:25PM -0800, Doug Evans wrote:
 > > It's odd that if the architectures (or mach's) are incompatible during
 > > a relocatable link it's automatically an error whereas in a final link
 > > it's only a warning and then only if the user asks for it.
 > > 
 > > Is there any reasoning behind this?
 > 
 > We might be able to use a "foreign" input file in a final link if the
 > generic linker support for that particular input is good enough.
 > For relocatable output, we'd need to translate relocs from one format
 > to another..

That's what the comment above the code essentially says.
Guess I didn't constrain my question enough. :-)

Suppose the architectures are the same and it's only the mach's
that are different (say different chip variants) and the variants
are not compatible.  [This is different than my original question, yes.]
The relocations are, however, identical between the two chip variants.
[I'm guessing that's often the case within the same architecture].

A relocatible link of these two chip variants will yield the error:

Relocatable linking with relocations from format elf32-foo (foo1.o) to format elf32-foo (foo2.o) is not supported

Not a very useful error message.
[ergo my request to include the printable names in the error message]

Furthermore, when doing a final link, it succeeds (or gives a warning
when requested), which is counter-intuitive to the user.

I understand and agree with the issue you're commenting on.
IMO the above situation is sufficiently different to warrant
different behaviour than the existing one.

I guess it comes down, in part, to:
- what does the result of bfd_arch_get_compatible mean?
- whether the code in question is using it correctly

bfd_arch_get_compatible is apparently being overloaded to mean
whether the relocations among the two arguments are compatible
and whether they're functionally compatible.
At least that's how the usage of bfd_arch_get_compatible appears to me.