From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 15 07:02:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EADA16A4CE; Mon, 15 Mar 2004 07:02:54 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0B4B43D39; Mon, 15 Mar 2004 07:02:53 -0800 (PST) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 280B854861; Mon, 15 Mar 2004 09:02:53 -0600 (CST) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21286-08; Mon, 15 Mar 2004 09:02:42 -0600 (CST) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 36E4954840; Mon, 15 Mar 2004 09:02:42 -0600 (CST) Received: by lum.celabo.org (Postfix, from userid 501) id 9A939167744; Mon, 15 Mar 2004 08:59:52 -0600 (CST) Date: Mon, 15 Mar 2004 08:59:51 -0600 From: "Jacques A. Vidrine" To: David Gilbert Message-ID: <20040315145951.GA10172@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , David Gilbert , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <16468.65270.123954.862565@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16468.65270.123954.862565@canoe.dclg.ca> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: GCC include files conundrum. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 15:02:55 -0000 On Sun, Mar 14, 2004 at 07:55:18PM -0500, David Gilbert wrote: > I attempted to argue that audio/tclmidi wasn't broken... and the ports > maintainer fired back with > > http://bento.freebsd.org/errorlogs/i386-5-latest/tclmidi-3.1.log > > Now... I started investigating this and found that this was all due to > some differences in C++ over the years. > > The error on bento comes down to bento not having strstream.h. I have > that file as: > > /usr/include/c++/3.3/backward/strstream.h > /usr/include/g++/backward/strstream.h > > on my -CURRENT (as of a week or two ago) laptop. > > bento does appear to have /usr/include/c++/3.3/backward/iostream.h > ... but not strstream.h. Why? FreeBSD stopped installing `strstream.h' in January. See rev 1.48 of src/gnu/lib/libstdc++/Makefile. The commit log indicates it was removed in (some release of) GCC 3.3. I wonder if this is correct though--- compiler messages seem to contradict this. > I realize that my source upgrading may have left around a few old > files, but I don't see a replacement strstream.h. > > The C++ FAQ referred to by iostream (not iostream.h) seems to imply > that you should use iostream and sstream (no .h)... but including > those files imposes a very different standard that this port is not > ready to accept. It appears that (among other things that I havn't > found yet) all 'istream' must be written 'std::istream' ... etc. > > So what's the solution? `strstream.h' was never a standard C++ header, but rather a part of SGI STL (I think) that is now obsolete. `strstream' is defined in ISO/IEC 14822:1998 and 2003, but is deprecated. (``This clause describes features of the C++ Standard that are specified for compatibility with existing implementations. These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.'') It looks to me like tclmidi uses only class ostrstream. The easiest solution to your problem would be to add a file named `strstream.h' with the following contents: #include using std::ostrstream; The longer term solution is to kill the port, or to port it to Standard C++. Porting it to Standard C++ would probably entail rewriting uses of and `ostrstream' to and `ostringstream'; and rewriting uses of other C++ `.h' headers to the standard form without .h; and adding `using namespace std;' liberally. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org