Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Looking at https://github.com/clang-omp/clang_trunk/blob/master/lib/Driver/MSVCToolChain.cpp shows that the modern source code has std::sscanf and use so that is likely the better direction to go. What I saw when I looked was: //===--- 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 // Include the necessary headers to interface with the Windows registry and // environment. ... if (!sdkVersion.empty()) std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); return hasSDKDir && !path.empty(); ... === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 01:24 PM, Mark Millard wrote: 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 . (So also no explicit include of , 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 . MSVCToolChain.cpp does not directly or indirectly include . 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 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 // 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 wrote: Adding a #include 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 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 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 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 '
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 . (So also no explicit include of , 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 . MSVCToolChain.cpp does not directly or indirectly include . 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 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 // 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 wrote: Adding a #include 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 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 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 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 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 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 and other times . (I did find with grep's.) One would have to trace all the headers actuall
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Adding a #include 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 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 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 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 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 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 and other times . (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 somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various vintages) has at least one vintage that uses vs. as an example for... "The header assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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 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 h
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
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 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 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 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 and other times . (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 somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various vintages) has at least one vintage that uses vs. as an example for... "The header assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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 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 wrote: Basic context (more context details listed late
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 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 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 and other times . (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 somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various vintages) has at least one vintage that uses vs. as an example for... "The header assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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 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 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 T
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 and other times . (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 somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various vintages) has at least one vintage that uses vs. as an example for... "The header assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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 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 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: 38029
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 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
> On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn wrote: > > 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 Quoting for the "which compiler" part: "It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed". The evidence for this was watching top -PaSCHopid while it worked on the installation. As for the FBSDG5C0 SSD's 11.0-CURRENT history for compilers: gcc 4.2.1 present. clang not present. (Not 3.4.1, not 3.5, not 3.6. 3.4.1 was lost in the 10.1-STABLE -> 11.0-CURRENT conversion when I did delete-old, not realizing that I'd end up with no clang at all and no obvious way to build one on the powerpc64s/powerpcs.) (None of the below were ever on any 10.1-STABLE SSD as of when I did the copies and conversion of some to 11.0-CURRENT.) powerpc64-xtoolchain-gcc present (and so powerpc64-gcc), installed recently for the first time ever. This was the first ever not-built-into-world compiler that I've installed on any media. The powerpc64-gcc installer has a file naming problem for powerpc64 hosts I had to put copies of 5 files that it created under the names it later looked for them to finish this install (names not prefixed -> prefixed, one file copied to another place). gcc5 installed just days ago, the second ever ports-compiler installed. The install had no problems. I will note that I have started an installation of lang/clang36 on a powerpc (non-64) 11.0-CURRENT that has/had only gcc 4.2.1 and clang 3.4.1. Watching with top -PaSCHopid shows that it is doing a lang/gcc installation as part of its bootstrap, at this point that means 4.8.4. So it is not using gcc 4.2.1. Again for this SSD there is no history of compiler installs other than those that are part of world. clang 3.4.1 exists because I did not get around to doing delete-old before I noticed that I ended up with no clang as a result. This is the only copy of clang 3.4.1 that survived my ignorance to end up on 11.0-CURRENT. I have another powerpc (non-64) 11.0-CURRENT SSD that does not have powerpc64-gcc nor clang but does have gcc5 already. Again gcc5 installed in the last few days. Again before the installation there had only ever been built-into-world compilers. I've started a lang/CLANG36 install here as well. We will see how each of these goes. Side note: You can tell I got past the booting/memory-corruption problems on the G5 PowerMacs recently (via Powermac specific builds). I'm now exploring other things in FreeBSD. :) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn wrote: 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 Auth
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"
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"
