From owner-freebsd-ppc@freebsd.org Fri Oct 20 22:09:51 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCCB4E41717 for ; Fri, 20 Oct 2017 22:09:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7398D67D74 for ; Fri, 20 Oct 2017 22:09:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2749 invoked from network); 20 Oct 2017 22:09:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Oct 2017 22:09:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 20 Oct 2017 18:09:49 -0400 (EDT) Received: (qmail 19464 invoked from network); 20 Oct 2017 22:09:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Oct 2017 22:09:48 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2E2F4EC8B8D; Fri, 20 Oct 2017 15:09:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: libc++ on FreeBSD-11.1 powerpc32 From: Mark Millard In-Reply-To: Date: Fri, 20 Oct 2017 15:09:47 -0700 Cc: Joe Nosay , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <14969DC7-E72B-4912-A4CE-014F9DB92FE0@dsl-only.net> References: To: Thaison Nguyen X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 22:09:51 -0000 On 2017-Oct-20, at 1:40 PM, Thaison Nguyen = wrote: > . . . > /bin/sh ../libtool --tag=3DCXX --mode=3Dcompile clang++50 = -DHAVE_CONFIG_H -I. -I/usr/local/include -O2 -pipe = -fno-strict-aliasing -MT tif_stream.lo -MD -MP -MF .deps/tif_stream.Tpo = -c -o tif_stream.lo tif_stream.cxx > libtool: compile: clang++50 -DHAVE_CONFIG_H -I. -I/usr/local/include = -O2 -pipe -fno-strict-aliasing -MT tif_stream.lo -MD -MP -MF = .deps/tif_stream.Tpo -c tif_stream.cxx -fPIC -DPIC -o = .libs/tif_stream.o > tif_stream.cxx:31:10: fatal error: 'iostream' file not found > #include > ^~~~~~~~~~ > 1 error generated. > *** [tif_stream.lo] Error code 1 > . . . It looks to me that, even if iostream from either libc++ or libstdc++ was present, the: -I. -I/usr/local/include would not normally be sufficient for finding the libc++ or libstdc++ related headers in the system headers (using amd64 as an example here, so, libc++): # find /usr/include/ -name iostream -print | more /usr/include/c++/v1/tr1/iostream /usr/include/c++/v1/iostream As for a gcc 4.2.1 based powerpc buildworld and its (old) libstdc++ (the below is from a cross build environment, not on powerpc itself): # find /usr/obj/DESTDIRs/gcc421-powerpc-installworld -name iostream = -print | more = =20 = /usr/obj/DESTDIRs/gcc421-powerpc-installworld/usr/include/c++/4.2/iostream= So, again, the -I usage looks insufficient for finding the C++ headers involved: -I/usr/include/c++/4.2 would find the system iostream file in this older context. You might be able to use the system libstdc++ and its headers if you can get the proper options to the compiles and links in your port builds. (This is not a type of experiment that I've done.) As I remember clang has a -stdlib=3Dlibstdc++ option and a -stdlib=3Dlibc++ option but I've never tried the non-default -stdlib=3Dlibstdc++ option and I do not know just what it is supposed to do differently than the default -stdlib=3Dlibc++ option. Going in a different direction. . . As far as I know there is no FreeBSD port that includes libc++ sources to build. Nor do any supply libstdc++ source to independently build as far as I know. If those are correct then you would be on your own for building and using either library independent of the system implementation of one or the other. Just FYI: Using lang/gcc7 as an example of its path to its own installed iostream file: # find /usr/local/ -name iostream -print | more = = =20 /usr/local/lib/gcc7/include/c++/iostream So again the C++ specific path would not be just . . ./include/ . This is a fairly general property for finding C++ headers and the detailed paths vary from library implementation to library implementation. =3D=3D=3D Mark Millard markmi at dsl-only.net