🚀 go-pugleaf

Environment:
  gcc-2.3.1 from aeneas, no modifications
  Next cube 68040, 16MB main memory, running NextSTEP 3.0
  gcc-2.3.1 _NOT_ previously installed (thus no fixed includes)

  #!/bin/sh
  # GCC was configured as follows:
  ../gcc-2.3.1/configure --srcdir=../gcc-2.3.1 --prefix=/usr/local/gnu next
  echo host=m68k-next-bsd target=m68k-next-bsd build=m68k-next-bsd

Bug:

  While making libgcc2.a at the end of the first pass of the build,
  "./xgcc -B./" is used on _eprintf, the preprocessor is in c mode.
  At this point, there is no GNU modified stdargs.h on the search path
  xgcc is using.  The NeXT, Inc. supplied /usr/include/ansi/stdargs.h
  is used which contains a C++ style comment having an unmatched
  single quote.  Cpp takes the unmatched single quote as the beginning
  of a character constant and swallows the rest of the file.  Because
  of the unmatched '#endif' directives that were swallowed, the
  compile fails.

  NOTE: If gcc-2.3.1 has been built and installed its 'fixed'
  includes, the stdarg.h _used_ does not contain this string and thus
  there is no problem with the gcc build.

  The file /NextDeveloper/Headers/ansi/m68k/stdarg.h contains the line:

    // BSD compatibility: if #include <varargs.h> seen, don't redefine per ANSI

  When read by cpp in C comment mode (rather than C++ comment mode)
  the rest of the file is considered part of a character constant.
  From the log of the build:

    _varargs
    _eprintf
    In file included from /NextDeveloper/Headers/ansi/machine/stdarg.h:11, from /NextDeveloper/Headers/ansi/stdarg.h:7, from /NextDeveloper/Headers/ansi/stdio.h:18, from ../gcc-2.3.1/libgcc2.c:1155:
    /NextDeveloper/Headers/ansi/m68k/stdarg.h:4: unterminated string or character constant
    /NextDeveloper/Headers/ansi/m68k/stdarg.h:30: unbalanced `#endif'
    *** Exit 1


Fix:

  As noted by Daryll Strauss, one can hack CPP_SPEC to be -lang-objc
  mode for all cpp invocations by gcc.  I agree with his further
  comment, "but forcing all preprocessing into objective-C mode
  doesn't seem to be the "right" solution."  In fact this has
  additional effects one may not desire.

  Instead, below is a minimal change modeled on an existing piece of
  NeXT specificity (line 3178 of the original cccp.c) which allows
  '#import' directives on a NeXT.  It only alters the commenting
  convention, not the the objective C and C++ language flags.

  I assert that this does the 'right' thing in as much as NeXT has
  decided that C++ style comments are allowable in Objective C and
  plain C.  Whether or not this decision of NeXT's is correct, failure
  to make such a change results in a compiler that cannot accept code
  written for the platform.

  For the pedantic, one might want to recognize the -pedantic flag and
  override this allowance of C++ style comments.  (I've revised my
  patch to do this.)

Prototype Change Log Entry:

  Tue Nov  3 09:21:15  Frederick Korz (korz@bach.cs.columbia.edu)

          * cccp.c: Make C++ style comments allowable by default on NeXT

Patch:

*** cccp.c.orig	Sat Oct 24 21:06:43 1992
--- cccp.c.new	Tue Nov  3 09:14:03 1992
*************** main (argc, argv)
*** 1472,1477 ****
--- 1472,1483 ----
        make_definition (pend_defs[i], &outbuf);
      }
  
+   if ( lookup ("__NeXT__", -1, -1) && !pedantic )
+     {
+       /* NeXT allows and uses C++ style comments in its headers. */
+       cplusplus_comments = 1;
+     }
+ 
    done_initializing = 1;
  
    { /* read the appropriate environment variable and if it exists

========================================================================

Fred Korz			450 Computer Science Building
korz@cs.columbia.edu		Columbia University
(212) 939-7068			NY, NY  10027 (USA)