This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alistair Francis <alistair23 at gmail dot com>
- Cc: Lukasz Majewski <lukma at denx dot de>, Zack Weinberg <zackw at panix dot com>, Arnd Bergmann <arnd at arndb dot de>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Date: Fri, 6 Sep 2019 21:28:39 +0000
- Subject: Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function
- Ironport-sdr: qNyZA8w0jEbjtKhhOBtx+ZQArQmENsD1gjQLiRaeSrCmyXiJ8wM/gsQvN/je5Wcyxggzxjq7/R PoRQWqETSbPpLuIZZAW9DTpsnmvnYyYYBTlsNrvzfyEyCTdGOEZqGnuyOOXIcAoVwDKr4CtkTM 1HCbDT+zk6ebwsX4OqKNqfVAaOnLhDnBJCUYjl7lia/4j+nyvCRrZBloJ+IDBqF/0skoHPsdq0 Vj7vXOatKxwz10kpW7BNkezUia4SGuTMcRnA5YLJBPsCpcR6dP3hBDtwYVXF7ACXqa51tntwlb Oak=
- Ironport-sdr: iRx4aWnpD2tRm/P9mzCXumCJrFgG8XDsF0y0dFh/d2W26LOqtxT5wklRTDI7S3VpvBvcI0TPd5 Pyub2Z9vqqDAMT66szQqHQZlzm0OoTBmkrWJL3Ndu+nIQ6HoAuUOKReklhqa697oCac6rr8/nh dfAGULc7ANjnugBANXc8mdncJ/GFZp6mhuCu+w5LB3W/Dc+H1gYJVBTrnpnyVebnTNOZdHyltM 0yplc5jI2vVSrSyQjoGvxTBppeuCHR36wZXwxdzD5C2X7q2YtvMq4E/Q/YszgkLwB0Yz0BZa96 cBI=
- References: <20190906145911.30207-1-lukma@denx.de> <CAKmqyKMdsVZg_ZS7fLTt23dy2vnZc1z85b_+8heiK-8UiqMx+g@mail.gmail.com>
On Fri, 6 Sep 2019, Alistair Francis wrote:
> Which I can fix with this diff:
This diff is not the right way to fix this build failure.
One of the design principles in the Y2038 support is that is __TIMESIZE ==
64, the time functions *aren't* trivial wrappers of time64 functions;
rather, the time64 function definitions are remapped (via macros) so they
define the function name with no "64". For each case where there is a
pair of functions (for different time_t types) in the __TIMESIZE == 32
case, there should just be the one function when __TIMESIZE == 64.
This ensures that the Y2038 changes don't add any overhead at all in the
glibc binaries on existing platforms with __TIMESIZE == 64.
You should look at exactly what the types in question are, that are being
reported as conflicting in your build (probably by looking at preprocessed
source). __timespec64 and timespec are supposed to be the same type (via
#define) when __TIMESIZE == 64, to avoid such incompatibilities.
--
Joseph S. Myers
joseph@codesourcery.com