Date: Tue, 17 Mar 2015 02:26:32 -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: <BECDC733-115B-44E6-98E4-5FE0EC9D5EA1@dsl-only.net> In-Reply-To: <4A490783-D724-4C81-A99E-0CBB20650559@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?BECDC733-115B-44E6-98E4-5FE0EC9D5EA1>