Skip site navigation (1)Skip section navigation (2)
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>