> [...] because of what I consider to be bugs in the binutils[*].

> [*] The bug is that the binutils directly access libbfd's selected
> targets vector, rather than calling libbfd functions (which don't
> exist, grr) to access the vector.  This means that the size of
> selected vector symbol changes, in this case growing by 4 bytes
> because 1 vector was added, and ld.so issues a warning and does only
> the "expected" size.

In my opinion this is a bug in ld.so.  How many more "bugs" are we
going to have to run into because of it before we fix it?

(Yes, it's fixable.  All you have to do is keep the size along with the
rest of the symbol info in the executable, then at ld.so time, if the
size has changed, resolve to the data segment of the library instead of
to the copy in data/bss space.  This means losing shared-library
sharing on the affected page(s), but really, it seems very penny-wise
and pound-foolish to consider that sharing precious enough to be worth
breaking library semantics like this for.  Besides, it can always be
cured by relinking, which is the cure for the present brokenness, and
surely it's better to be slightly inefficient until relinked than to be
coredump-level broken until relinked.)

As for this particular case (and the other one, too - IIRC it was
sys_errlist[]), why not declare the array const, which should push it
into the text segment, in which case the size clash issue completely
vanishes?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B