From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 05:36:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E9CAA23 for ; Tue, 17 Mar 2015 05:36:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 45A04102 for ; Tue, 17 Mar 2015 05:36:53 +0000 (UTC) Received: (qmail 3343 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 05:36:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 01:36:52 -0400 (EDT) Received: (qmail 24173 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 05:36:52 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id DCEA41C4052; Mon, 16 Mar 2015 22:36:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> Date: Mon, 16 Mar 2015 22:36:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 05:36:54 -0000 The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net