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.
===
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::string&,
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.)
===
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-NODEBUG
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=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]"
