Re: Proposed CHOST change for the 64bit time_t transition

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bruno Haible <[email protected]> writes:

> Arsen Arsenovi=C4=87 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.

I mentioned that a missing pair should not preclude linking.  This is
because what I imagined is somehow attaching this tag to the typedef for
time_t, or such, so if the typedef is not used, no such tag is emitted.

I'm not sure how feasible that is, I, of course, don't have a full
implementation.
=2D-=20
Arsen Arsenovi=C4=87

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOcEARYKAI8WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZtw+kV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF
MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxEcYXJzZW5AZ2Vu
dG9vLm9yZwAKCRBSwpQwHqLEk99pAQCKLodLpIQF5XrOTrvxS6zMlsJGZH14UEMK
Ebm4xjitowEA+B3jHbb77fkhKT81ra3nUNzLlZ5nWWO5Ss+fFz90gAU=
=3RYl
-----END PGP SIGNATURE-----
--=-=-=--