From nobody@FreeBSD.org  Tue Jul  9 12:00:59 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	by hub.freebsd.org (Postfix) with ESMTP id 7EB5E623
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  9 Jul 2013 12:00:59 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121])
	by mx1.freebsd.org (Postfix) with ESMTP id 58E0E1BBC
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  9 Jul 2013 12:00:59 +0000 (UTC)
Received: from oldred.freebsd.org ([127.0.1.6])
	by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r69C0wIg051443
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 9 Jul 2013 12:00:58 GMT
	(envelope-from nobody@oldred.freebsd.org)
Received: (from nobody@localhost)
	by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r69C0wwf051426;
	Tue, 9 Jul 2013 12:00:58 GMT
	(envelope-from nobody)
Message-Id: <201307091200.r69C0wwf051426@oldred.freebsd.org>
Date: Tue, 9 Jul 2013 12:00:58 GMT
From: Mike Gelfand <mike@iaso.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Compilation failure with _DONT_USE_CTYPE_INLINE_ defined
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         180413
>Category:       misc
>Synopsis:       [build] [patch] Compilation failure with _DONT_USE_CTYPE_INLINE_ defined
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 09 12:10:00 UTC 2013
>Closed-Date:    
>Last-Modified:  Tue Jul 09 17:22:25 UTC 2013
>Originator:     Mike Gelfand
>Release:        9.1
>Organization:
IASO Backup
>Environment:
FreeBSD build-machine-BSD9.1 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
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.
>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 -----
>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 -----

>Release-Note:
>Audit-Trail:
>Unformatted:
