Arsen Arsenović wrote:
> An alternative that I pondered was to teach the linker about some notion
> of "compatibility strings" that it would compare and reject if
> different, plus teaching the compiler how to emit those, plus teaching
> glibc to tell the compiler to emit those.. We could have key-value
> pairs in some section. For each key K, we could have the linker check
> that, for each (shared or otherwise) object either does not contain K or
> contains K with the same value as all the other ones, and produce an
> error otherwise. On the resulting object, the KV pairs would be the
> union of all KV pairs of all constituent objects.
This sounds much like the arm eabi attributes: If a .s file does not
start with
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
the resulting .o file cannot be linked with other .o files on the system.
Is it a hassle even for packages that don't use time_t of off_t (such as
GNU libffcall or libffi).
Yes, it would be useful to have a way to have the linker warn if a binary
that depends on 32-bit time_t and a binary that depends on 64-bit time_t
get linked together. But PLEASE implement this in a way that is a no-op
when time_t is not used by either of the two binaries.
Bruno
