https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118009
Bug ID: 118009
Summary: Obsolete fixincludes hack for glibc-2.3.3 interferes
with 64-bit time_t changes in modern glibc's pthread.h
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Originally reported downstream in Gentoo at https://bugs.gentoo.org/933282.
We enabled fixincludes in our GCC builds for a period to pick up
r13-3148-g348e46fa8cba96 to keep things building with older glibc until new
glibc was released (or whatever the ordering was), then disabled it later
unless old glibc was installed. Fine.
By enabling fixincludes, pthread.h also started to be modified for a
long-obsolete problem on modern systems (PR20166, r0-66687-g14bfd7c70da285).
This wasn't a problem at first. The change is:
```
@@ -779,7 +770,7 @@
#else
# define __sigsetjmp_cancel(env, savemask) \
__sigsetjmp ((struct __jmp_buf_tag *) (void *) (env), (savemask))
-extern int __sigsetjmp (struct __jmp_buf_tag *__env,
+extern int __sigsetjmp (struct __jmp_buf_tag __env[1],
int __savemask) __THROWNL;
#endif
```
The problem is, when doing 64-bit time_t porting in glibc itself, pthread.h was
modified upstream with changes like (the opposite of below):
```
@@ -232,7 +223,7 @@
the thread in *THREAD_RETURN, if THREAD_RETURN is not NULL. */
extern int pthread_tryjoin_np (pthread_t __th, void **__thread_return)
__THROW;
-# ifndef __USE_TIME_BITS64
+# ifndef __USE_TIME64_REDIRECTS
```
When GCC was built w/ fixincludes enabled, an old fixincluded'd version of the
headers is used which has the old time64 macro, and therefore
__pthread_cond_timedwait64 isn't being made available.
This could be avoided if we can either:
a) drop the old pthread.h fixincludes hack, given it was for glibc-2.3.3, or
b) scope it to specific glibc versions somehow.
