Re: c++/1688: Includes causing extern "C" not to behave correctly(?)

[Daniel Henninger <daniel@unity.ncsu.edu>]

The following reply was made to PR c++/1688; it has been noted by GNATS.

From: Daniel Henninger <daniel@unity.ncsu.edu>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/1688: Includes causing extern "C" not to behave correctly
 (?)
Date: Thu, 18 Jan 2001 12:43:04 -0500 (EST)

 > > After scanning the preprocessor output and everything we can
 > > not come up with anything that "makes sense" as to why it's
 > > not working.
 >
 > CPP treats extern "C" things slightly differently if they're #include
 > <>'d rather than #include ""'d.  Is that the issue?
 
 Nope, 'fraid not.  The only difference between it working and not
 working is whether the include path for the X libraries was directly
 specified.  In all instances it is included with <>.  "" produces the same
 results though, I just tested it.
 
 FWIW, -fpermissive =does= allow it to compile, by turning every one of the
 errors into a warning.  Another thing to note, when I compile it without
 -I/usr/openwin/include, it produces no output what-so-ever, just compiles
 and is happy.
 
 > Look at the # LINENO directives created.  Are they different?  (The
 > flag "4" at the end is to do with extern "C").
 
 < # 1 "/usr/include/X11/Xlib.h" 1 3 4
 > # 1 "/usr/openwin/include/X11/Xlib.h" 1
 
 The second one is where -I/usr/openwin/include was directly specified in
 the include path.  And of course:
 stonecold [12:37pm] ~> ls -ld /usr/include/X11
 lrwxrwxrwx   1 root     root          22 Jan 21  2000 /usr/include/X11 ->
 ../openwin/include/X11
 
 They are one in the same.  So the 4 at the end of the first has to do with
 the extern "C" directive?  How about the 3?  What's that for?
 
 Daniel
 
 -- 
 /\\\----------------------------------------------------------------------///\
 \ \\\      Daniel Henninger     http://genjuro.eos.ncsu.edu/daniel       /// /
  \_\\\      North Carolina State University - Systems Programmer        ///_/
     \\\                   Information Technology <IT>                  ///
      """--------------------------------------------------------------"""
 
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1058
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010208090603.23292.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01058.html
Content-length: 662

The following reply was made to PR c++/1058; it has been noted by GNATS.

From: lerdsuwa@gcc.gnu.org
To: Kristjan.Haule@ijs.si, gcc-gnats@gcc.gnu.org,
  haule@tkm.physik.uni-karlsruhe.de, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1058
Date: 8 Feb 2001 08:59:26 -0000

 Synopsis: gcc version 2.95.2 produces "parse error before `>'"
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: lerdsuwa
 State-Changed-When: Thu Feb  8 00:59:26 2001
 State-Changed-Why:
     This is a known bug.  A workaround is to use
       a.template set<B>(3,2.2);
     instead of
       a.set<B>(3,2.2);
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1058&database=gcc
>From james.mcininch@cereon.com Sun Apr 01 00:00:00 2001
From: james.mcininch@cereon.com
To: gcc-gnats@gcc.gnu.org
Cc: suavek.rucinski@cereon.com
Subject: c/1946: Coinfiguration script ignores --program-suffix parameter
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010212152000.6316.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01173.html
Content-length: 1120

>Number:         1946
>Category:       c
>Synopsis:       Coinfiguration script ignores --program-suffix parameter
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 12 07:26:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     James D. McIninch
>Release:        Reading specs from /opt/share/lib/gcc-lib/sparcv9-sun-solaris2.8/2.97/specs
>Organization:
>Environment:

>Description:
Upon doing 'make install', all exectuables are installed
without the specified program suffix except 'fastjar' which,
in this case, was properly installed as 'fastjar64' (note,
that LANGUAGES was set to "c c++", so it's not clear that
fastjar should have been built and installed at all).
>How-To-Repeat:
./configure --program-suffix=64
make LANGUAGES="c c++"
make install
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 Configured with: ./configure --program-suffix=64 --prefix=/opt/share --enable-shared --enable-multilib sparcv9-sun-solaris2.8
 gcc version 2.97 20010122 (experimental)