I've compiled our software on 9.1 and then tried running it on 8.3. Apparently, there is a binary incompatibility leading to _ThreadRuneLocale symbol not being resolved. So I decided to workaround the issue by compiling with _DONT_USE_CTYPE_INLINE_ define. Than helped in the way that the aforementioned symbol is no longed being imported by the binary, but while I was trying to compile, the issue I'm now writing about appeared. When _DONT_USE_CTYPE_INLINE_ defined is being used, compilation fails since /usr/include/runetype.h is no longer being included by /usr/include/_ctype.h, which in turn leads to _RuneLocale struct being undefined, while still used in /usr/include/xlocale/_ctype.h. Fix: I used this simple patch below, but I know it's not a good one, so you are free to fix it properly :) -----8<----- patch begin ----- --- /usr/include/_ctype.h.orig +++ /usr/include/_ctype.h @@ -85,14 +85,14 @@ extern int __mb_sb_limit; +#include <runetype.h> + /* * Use inline functions if we are allowed to and the compiler supports them. */ #if !defined(_DONT_USE_CTYPE_INLINE_) && \ (defined(_USE_CTYPE_INLINE_) || defined(__GNUC__) || defined(__cplusplus)) -#include <runetype.h> - static __inline int __maskrune(__ct_rune_t _c, unsigned long _f) { --- /usr/include/runetype.h.orig +++ /usr/include/runetype.h @@ -82,6 +82,9 @@ int __variable_len; /* how long that data is */ } _RuneLocale; +#if !defined(_DONT_USE_CTYPE_INLINE_) && \ + (defined(_USE_CTYPE_INLINE_) || defined(__GNUC__) || defined(__cplusplus)) + #define _RUNE_MAGIC_1 "RuneMagi" /* Indicates version 0 of RuneLocale */ __BEGIN_DECLS extern const _RuneLocale _DefaultRuneLocale; @@ -103,4 +106,6 @@ #define _CurrentRuneLocale (__getCurrentRuneLocale()) __END_DECLS +#endif /* _DONT_USE_CTYPE_INLINE_ */ + #endif /* !_RUNETYPE_H_ */ -----8<----- patch end ----- How-To-Repeat: Compile this small sample: -----8<----- code begin ----- #define _DONT_USE_CTYPE_INLINE_ #include <ctype.h> int main() { return 0; } -----8<----- code end -----
I am not sure what the bug is here. We do not guarantee forward compatibility, only backward compatibility. Code compiled on 8.3 should run on 9.1, but not the converse. In particular, in 9.x we added a (POSIX2008-compilant) per-thread locale and explicit locales. For efficiency, various ctype.h functions are inlines. When compiled on 8.x, these will always refer to the global locale. When compiled with 9.x, they will refer to the thread-local locale if one is set or the global locale if not. If you want to target 8.x, then you should use the headers from 8.x (ideally, we'd add visibility attributes to all of the headers to allow you to target older versions, but we have not done this for any other system headers and so there should be no expectation that this will work in the general case).
Ah, I see, the running on 8.3 was a red herring. This looks like a real issue. I'll take a look. The _ctype.h header needs to be modified to provide non-inline definitions of the functions and we'll need to add them to libc.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>