From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 20:24:46 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9523B646 for ; Tue, 17 Mar 2015 20:24:46 +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 485966C4 for ; Tue, 17 Mar 2015 20:24:45 +0000 (UTC) Received: (qmail 385 invoked from network); 17 Mar 2015 20:24:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 20:24:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 16:24:43 -0400 (EDT) Received: (qmail 12690 invoked from network); 17 Mar 2015 20:24:43 -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 20:24:43 -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 A11B91C43A6; Tue, 17 Mar 2015 13:24:38 -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: Date: Tue, 17 Mar 2015 13:24:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@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-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:24:46 -0000 I tried the final experiment using std::sscanf (so: adding the std) in = to the official port's MSVCToolChain.cpp source without adding an = explicit include of . (So also no explicit include of , = just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: 'sscanf' is not a member of 'std' std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ In other words for the official port's source code (by the above and = prior reported experiments): MSVCToolChain.cpp does not directly or indirectly include . MSVCToolChain.cpp does not directly or indirectly include . At that point it is shear luck for there to be any = declaration/definition of either ::sscanf or std::sscanf. Apparently gcc = 4.8.4 is implicitly providing one someplace for at least ::sscanf. gcc5 = and gcc 4.9.3 do not. I do not see any reason to depend on such gcc-version-specific behavior. In my view MSVCToolChain.cpp should have: #include added. So the = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/MSVCToolChain.cpp code would start with something like (once = patched?)... (Warning: MSVCToolChain.cpp's initial comment misnames the file name.) //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #include "ToolChains.h" #include "clang/Basic/CharInfo.h" #include "clang/Basic/Version.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/DriverDiagnostic.h" #include "clang/Driver/Options.h" #include "llvm/ADT/StringExtras.h" #include "llvm/Config/llvm-config.h" #include "llvm/Option/Arg.h" #include "llvm/Option/ArgList.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/FileSystem.h" #include "llvm/Support/Process.h" #include // Include the necessary headers to interface with the Windows registry = and // environment. ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard = wrote: Adding a #include to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling = MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and = installation to complete. The official MSVCToolChain.cpp for the port does not directly or = indirectly include a header that guarantees to declare/define ::sscanf. = But it should. An alternative to the #include is to instead use std::sscanf notation. = That will be the next experiment to check if had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = wrote: Please excuse all the "gcc491" references. It is lang/gcc49 and = currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc = experiments. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: 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