Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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@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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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@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,
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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::string, 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.) //===--- ToolChains.cpp - ToolChain Implementations ---===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===--===// #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. ... === 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. === 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
powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Which compiler are you building with? Just using the normal lang/gcc works for me without issue doing make install in lang/clang36. Are you sure you don't have any local diffs or stale files? -Nathan On 03/16/15 17:18, Mark Millard 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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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:
