Re: need for flag for incompatible-changes

[Paul Koning <pkoning@xedia.com>]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

 >> If object files contained version numbers, you wouldn't have to
 >> break anything.  (More precisely, you would only have to break
 >> things that are older than the oldest version you want to continue
 >> supporting in the linker.)

 Joe> Where we have control over the linker (Linux, or platforms where
 Joe> GNU ld will work), we could use the linker to handle some types
 Joe> of incompatibilities.  In many cases, I'm afraid that all it
 Joe> will lets us do is say "sorry, incompatible object files".

Good point, I was silently assuming GNU ld.  If version number is
encoded in a way that doesn't bother other linkers (e.g., by a magical
global symbol) then users of other linkers would be no worse off than
they would be otherwise.

I wonder about the comment that even GNU ld often would only be able
to say "sorry, incompatible object files".  Some things, like naming
(namespace support) clearly aren't like that.  Similarly, adding a
handler type to the exception table shouldn't be a problem either (the
linker can supply the implied default value when it sees an old
table).

It seems to me that the ability to create a backwards compatibility
mechanism should be a design goal, and a high priority one at that.
In other words, if a feature requires an object format change, it
should be done in such a way that the linker can continue to accept
both old and new formats and make the right things happen -- unless it
is really and truly impossible to do that.  (Are there examples where
that is so?)

Again, using network protocol design as a precedent here, there are
many cases where not having the goal caused incompatible protocols to
be designed, but I can't think of one where, once the goal was put in
place, it was found to be impossible to meet.  Yes, it does make
things harder, though usually not by much.  But the benefit obtained
is very large.  Flag days are *bad news*...

	paul