Cygwin: rename __sFILE to __sFILE64 for backward compatibility
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we were using the type __sFILE64 even for 64 bit. That was lazy and wrong. so commit2902b3a09e
("Cygwin: drop requirement to build newlib's stdio64") tried to fix that. Unfortunately this patch forgot to take the exposure of the typename __sFILE64 in userspace into account. This leads to trouble in C++ due to name mangling. Fix this by redefining __sFILE to __sFILE64. The type name is very much internal, so it doesn't really matter, except for the fact that it needs to stay backward compatible so as not to break building against C++ libs built under older versions of Cygwin. Fixes:2902b3a09e
("Cygwin: drop requirement to build newlib's stdio64") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This commit is contained in:
parent
53ea7b2d5a
commit
0f376ae220
|
@ -49,6 +49,12 @@ extern inline struct _reent *__getreent (void)
|
|||
|
||||
#define __FILENAME_MAX__ 4096 /* Keep in sync with PATH_MAX in limits.h. */
|
||||
|
||||
/* Unfortunately we defined __LARGE64_FILES until Cygwin 3.3.6, so
|
||||
FILE was based on `struct __sFILE64'. The name is exposed into
|
||||
userspace and consequentially used in C++ name mangling. We must
|
||||
redefine __sFILE as __sFILE64 to stay backward compatible. */
|
||||
#define __sFILE __sFILE64
|
||||
|
||||
/* The following block of macros is required to build newlib correctly for
|
||||
Cygwin. Changing them in applications has no or not the desired effect.
|
||||
Just leave them alone. */
|
||||
|
|
Loading…
Reference in New Issue