Date: Tue, 17 Mar 2015 13:24:41 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, freebsd-ports@freebsd.org Cc: freebsd-toolchain@freebsd.org Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared Message-ID: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> In-Reply-To: <AA9E1107-CA65-4411-BB28-A9B9623E9771@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <E0F20237-485C-445B-A269-531AE092AEF0@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> <BECDC733-115B-44E6-98E4-5FE0EC9D5EA1@dsl-only.net> <AA9E1107-CA65-4411-BB28-A9B9623E9771@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <cstdio>. (So also no explicit include of <stdio.h>, =
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 <cstdio>.
MSVCToolChain.cpp does not directly or indirectly include <stdio.h>.
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 <stdio.h>
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 <stdio.h>
// 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 <markmi at dsl-only.net> =
wrote:
Adding a
#include <stdio.h>
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 <cstdio> 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 <markmi at dsl-only.net> =
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 <markmi at dsl-only.net> =
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 <stdio.h>
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 <markmi at dsl-only.net> =
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 <stdio.h> and other times <cstdio>. (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 <stdio.h> =
somewhere for that context. (Having <cstdio> in addition is fine.)
The rule is as follows, using an example. The C++ standard (various =
vintages) has at least one vintage that uses <cstdlib> vs. <stdlib.h> as =
an example for...
"The header <cstdlib> assuredly provides its declarations and =
definitions within the namespace std. It may also provide these names =
within the global namespace. The header <stdlib.h> 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...
<cstdio> only guarantees:
int std::sscanf( const char* buffer, const char* format, ... );
<stdlib.h> 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 <markmi at dsl-only.net> =
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 <markmi at dsl-only.net> =
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7A4844FD-8AF2-4431-ADC2-F172626097B1>