default  Access: edit PLT Bugs
Main PageCreateQuick QueryStandard QueryAdvanced QueryHelp
Edit

View Problem Report: 9505

or send email to interested parties or send email followup to audit-trail
Reporter's email: hag@linnaean.org
Number: 9505
Category: mzscheme
Synopsis: mzscheme 4.0 build problems on netbsd 4.0 i386
Class: sw-bug
Responsible: mflatt
Notify-List:
Severity: serious
Priority: medium
State: closed
Confidential: no
Arrival-Date: Sat Jun 14 14:20:01 -0400 2008
Closed-Date:
Last-Modified: Fri Nov 14 20:32:18 -0500 2008
Originator: Daniel Hagerty
Organization: plt
Submitter-Id: unknown
Release: 4.0
Environment:
Description: mzscheme 4.0 fails to build out of the box on netbsd-4.0-i386.  So far all of the problems I've had stem from the apparent incestuousness xform.ss.

NetBSD's libc floating point has a couple of additional floating point functions that need to be listed in xform.ss's non-functions list: __isinfd __isnanf __isnand

Adding these gets past the first problem where bool.c and number.c explode running through xform.ss with "function $mumble declared __xform_nongcing__, but includes a function call".

Next problem I haven't figured out how to fix yet:  A bunch of wx related C++ files fail to compile with "redeclaration of C++ built-in type 'wchar_t'".  The typedef is somehow part of the system include files (specifically machine/ansi.h) that gets added in by xform.ss running source through g++ -E.

I would naively think that my system include files shouldn't be adding a wchar_t typedef to C++ code, but the compiler has shown itself good on many megabytes of prior C++, so there's something more complicated going on here, but I don't know what.

I will eventually dig more deeply, but thought it would be good to get the bug report in while I work on other things.
File Attachments:
How-To-Repeat:
Fix:
Release-Note:
Unformatted:

or send email to interested parties or send email followup to audit-trail

Audit Trail:

From: Daniel Hagerty <hag@linnaean.org>
To: bugs@plt-scheme.org
Cc: 
Subject: Re: [plt-bug] all/9505: mzscheme 4.0 build problems on netbsd 4.0 i386
Date: Sun, 15 Jun 2008 00:32:15 -0400

     Quite a train wreck.
 
 g++ -E output has a typedef for wchar_t in it, and it can do that
 because it also emits a line number tag that marks the source as a
 system header file and supresses some errors (like a typedef of
 wchar_t being an error).
 
 The transmogrification that xform.ss does removes the line number tag
 and so gets flagged as an error.
 
 What I ended up doing was changing xform.ss to omit typedefs for
 wchar_t if it's processing C++ source (C source got unhappy w/o the
 typedef).
 
 Patch for my changes to get it minimally working on this system
 attached.  Might be a better way to go about it.
 
 --- collects/compiler/private/xform.ss.orig	2008-03-29 08:48:59.000000000 -0400
 +++ collects/compiler/private/xform.ss	2008-06-14 23:45:28.000000000 -0400
 @@ -836,6 +836,7 @@
 
                 strlen cos sin exp pow log sqrt atan2
                 isnan isinf fpclass _fpclass _isnan __isfinited __isnanl
 +	       __isinfd __isnanf __isnand
                 __isinff __isinfl isnanf isinff
                 floor ceil round fmod fabs __maskrune _errno __errno
                 isalpha isdigit isspace tolower toupper
 @@ -1377,9 +1378,11 @@
                       (unused-struc-typedef? e))
                   null
                   (begin
 -                   (when pgc?
 -                     (check-pointer-type e))
 -                   e))]
 +                   (if pgc?
 +		       (if (check-pointer-type e)
 +			   null
 +			   e)
 +		       e)))]
              [(proc-prototype? e)
               (let ([name (register-proto-information e)])
                 (when (eq? (tok-n (car e)) '__xform_nongcing__)
 @@ -1735,7 +1738,11 @@
                                                 pointers)
                                         (append l non-pointers))))])
              (set! pointer-types (append pointers pointer-types))
 -            (set! non-pointer-types (append (map car non-pointers) non-pointer-types))))
 +            (set! non-pointer-types (append (map car non-pointers) non-pointer-types))
 +
 +	    (and source-is-c++?
 +		 (pair? non-pointers)
 +		 (eq? 'wchar_t (caar non-pointers)))))
 
          ;; get-vars : tok-list str bool -> (values list-of-(cons sym vtype) list-of-(cons sym vtype))
          ;; Parses a declaration  of one line (which may have multiple, comma-separated variables).

State changed from "open" to "analyzed" by mflatt at Sun, 15 Jun 2008 07:39:58 -0400
Reason>>> Added the three "non-functions". (We have a tool that avoids this sort
of dependence on known non-GCing functions, but it has never quite made
it to production, so far.) 

The wchar_t problem sounds familiar, but I think we saw it previously
when pre-processing through `gcc -E' instead of `g++ -E', and the
makefile seems to be correctly using `g++ -E'.

From: Daniel Hagerty <hag@linnaean.org>
To: bugs@plt-scheme.org
Cc: 
Subject: Re: [plt-bug] mzscheme/9505 mzscheme 4.0 build problems on netbsd 4.0 i386
Date: Sun, 15 Jun 2008 17:11:38 -0400

     Yes, this isn't an issue with using the gcc rather than g++ .
 
 The setup for netbsd's header files will always emit a typedef for
 wchar_t, even when processing C++.  The header files can do so knowing
 that g++ has been instructed to supress the error.  xform.ss doesn't
 preserve what's needed for the supression.
 
 As wchar_t is a language supplied type in C++, it seems that xform.ss
 omitting any typedef of wchar_t is a reasonable thing to do.  At least
 on this system, the typedef was still needed for C code.
From: Daniel Hagerty <hag@linnaean.org>
To: bugs@plt-scheme.org
Cc: 
Subject: Re: [plt-bug] mzscheme/9505 mzscheme 4.0 build problems on netbsd 4.0 i386
Date: Thu, 14 Aug 2008 15:21:43 -0400

     wchar_t problems are still present in 4.1.

State changed from "analyzed" to "closed" by mflatt at Fri, 14 Nov 2008 20:32:18 -0500
Reason>>> For the next release, xform preserves source line information,
including the flag indicating whether the code originated
from a system header.