Bug 180413 - [build] [patch] Compilation failure with _DONT_USE_CTYPE_INLINE_ defined
Summary: [build] [patch] Compilation failure with _DONT_USE_CTYPE_INLINE_ defined
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: David Chisnall
Depends on:
Reported: 2013-07-09 13:10 UTC by Mike Gelfand
Modified: 2018-05-28 19:41 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gelfand 2013-07-09 13:10:00 UTC
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.


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 */
 extern const _RuneLocale _DefaultRuneLocale;
@@ -103,4 +106,6 @@
 #define _CurrentRuneLocale (__getCurrentRuneLocale())
+#endif /* _DONT_USE_CTYPE_INLINE_ */
 #endif /* !_RUNETYPE_H_ */
-----8<----- patch end -----
How-To-Repeat: Compile this small sample:

-----8<----- code begin -----
#include <ctype.h>
int main() { return 0; }
-----8<----- code end -----
Comment 1 David Chisnall freebsd_committer 2014-06-02 08:25:27 UTC
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).
Comment 2 David Chisnall freebsd_committer 2014-07-25 13:18:07 UTC
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.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:41:39 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

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.