powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

Tue Mar 17 17:57:07 UTC 2015

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.

===
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.

===
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.

===
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.

===
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 at 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 at 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