Code compiles on Windows and Linux but not Mac - macos

I am compiling a project on multiple platforms with the c++0x flag. The only platform I am having trouble on is Mac. It seems to get upset over things that other compilers let slide. I am using Mac 10.8, Qt 5.3.2 with the following version of clang.
clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
This is the error it is generating.
In file included from src/qt/bitcoin.cpp:5:
In file included from ../../Qt5.3.2/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/QApplication:1:
In file included from ../../Qt5.3.2/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/qapplication.h:45:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qcoreapplication.h:45:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qglobal.h:78:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qcompilerdetection.h:846:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:254:9: error: field has incomplete type 'CScript'
_T2 second;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1994:27: note: in instantiation of template class 'std::__1::pair<const CScriptID, CScript>'
requested here
decltype(__is_constructible_test(declval<_Tp>(), declval<_Args>()...))
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2043:14: note: in instantiation of template class 'std::__1::__is_constructible<false,
std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public __is_constructible<is_scalar<_Tp>::value || is_reference<_Tp>::value,
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2069:14: note: in instantiation of template class
'std::__1::__is_constructible_void_check<false, std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public __is_constructible_void_check<__contains_void<_Tp, _Args...>::value
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2549:34: note: in instantiation of template class
'std::__1::is_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: __is_nothrow_constructible<is_constructible<_Tp, _Args...>::value, _Tp, _Args...>
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2671:14: note: in instantiation of template class
'std::__1::is_nothrow_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public is_nothrow_constructible<_Tp>
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/map:840:13: note: in instantiation of template class
'std::__1::is_nothrow_default_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> > >' requested here
is_nothrow_default_constructible<allocator_type>::value &&
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__config:332:34: note: expanded from macro '_NOEXCEPT_'
# define _NOEXCEPT_(x) noexcept(x)
^
src/keystore.h:43:7: note: in instantiation of exception specification for 'map' requested here
class CBasicKeyStore : public CKeyStore
^
src/serialize.h:28:7: note: forward declaration of 'CScript'
class CScript;
^
src/keystore.h:116:5: note: implicit default constructor for 'CBasicKeyStore' first required here
CCryptoKeyStore() : fUseCrypto(false)
^

I am having the same problem, it seems to be related with clang and c++11.
My scenario:
- Mac osx 10.10.1 yosemite
- Xcode 6.1 with Command Line tools 6.1
- Gnu make 3.81
- gcc -v:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
No homebrew, no macports, just some dependencies compiled by hand.
I am trying to compile for x86_64.
Any clue?
My idea could be recompile every dependency with gcc instead of clang, but I still had not time to test it, maybe it works for you ;)

Related

error: no member named 'async' in namespace 'std'

I know that std::async is a C++11 thing but I am pretty sure that my compiler has C++11 support.
#include <future>
using namespace::std;
void functionToRun() {
// some code
}
int main() {
auto x = 2; // throws warning warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
std::future<void> metricLoggerFuture = std::async(std::launch::async, functionToRun); // throws error no member named 'async' in namespace 'std'
}
and if I use
std::future<void> metricLoggerFuture = async(std::launch::async, functionToRun); // error: use of undeclared identifier 'async'
Also g++ --version shows
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I have gone through the following,
No member named 'size' in namespace 'std'
No Member named stoi in namespace std
Also,
OS: macOS Catalina
This code is part of a bigger project (wrapper over TigerVNC) so there is a makefile, but since auto complies without any issues I don't think C++11 is the issue and hence passing -std=c++11 in the CXXFLAGS and CPPFLAGS also doen't help.
Looks like you are not compiling with c++11, add -std=c++11 (or later) to your compiler command line or makefile.

macOS command line tools and gcc suddenly failing on Catalina (worked on Mojave)

Command Line tools are giving a multitude of errors when trying to install MuJoCo. I suspect with high confidence that this is an issue from the command line tools on my macOS Catalina since I have installed mujoco previously on Mojave and multiple ubuntu machines. The following installations had worked on Mojave.
First I perform:
xcode-select --install
Further information:
(base) ryanr#RRMBP ~ % /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I install using pip3 install 'mujoco-py<2.1,>=2.0'
I am greeted with errors as the following:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:443:34:
> error: expected declaration specifiers before
> '__OSX_AVAILABLE_STARTING' int getiopolicy_np(int, int)
> __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
> ^~~~~~~~~~~~~~~~~~~~~~~~
and
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:144:1: error: expected declaration specifiers before 'div_t'
div_t div(int, int) __pure2;
^~~~~
and
In file included from /Users/ryanr/.mujoco/mujoco200/include/mujoco.h:34:0,
from /private/var/folders/q7/q_59j36d5n31209r5c01mx2w0000gp/T/pip-install-4_wykvnc/mujoco-py/mujoco_py/gl/glshim.h:4,
from /private/var/folders/q7/q_59j36d5n31209r5c01mx2w0000gp/T/pip-install-4_wykvnc/mujoco-py/mujoco_py/gl/dummyshim.c:1:
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:59:19: error: storage class specified for parameter 'float_t'
typedef float float_t;
^~~~~~~
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:60:20: error: storage class specified for parameter 'double_t'
typedef double double_t;
^~~~~~~~
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:126:12: error: storage class specified for parameter '__math_errhandling'
extern int __math_errhandling(void);
^~~~~~~~~~~~~~~~~~
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:146:12: error: storage class specified for parameter '__fpclassifyf'
extern int __fpclassifyf(float);
^~~~~~~~~~~~~
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:147:12: error: storage class specified for parameter '__fpclassifyd'
extern int __fpclassifyd(double);
^~~~~~~~~~~~~
/usr/local/Cellar/gcc#6/6.5.0_2/lib/gcc/6/gcc/x86_64-apple-darwin18.5.0/6.5.0/include-fixed/math.h:148:12: error: storage class specified for parameter '__fpclassifyl'
extern int __fpclassifyl(long double);
^~~~~~~~~~~~~
and
^
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:110:0,
from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:66,
from /Users/ryanr/.mujoco/mujoco200/include/mujoco.h:33,
from /private/var/folders/q7/q_59j36d5n31209r5c01mx2w0000gp/T/pip-install-jye6hn52/mujoco-py/mujoco_py/gl/glshim.h:4,
from /private/var/folders/q7/q_59j36d5n31209r5c01mx2w0000gp/T/pip-install-jye6hn52/mujoco-py/mujoco_py/gl/dummyshim.c:1:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:443:9: error: old-style parameter declarations in prototyped function definition
int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
^~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:443:1: error: parameter name omitted
int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
^~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:443:1: error: parameter name omitted
/private/var/folders/q7/q_59j36d5n31209r5c01mx2w0000gp/T/pip-install-jye6hn52/mujoco-py/mujoco_py/gl/dummyshim.c:37:1: error: expected '{' at end of input
}
^
error: command '/usr/local/bin/gcc-6' failed with exit status 1
----------------------------------------
ERROR: Failed building wheel for mujoco-py
Any suggestions as to why my command-line tools are failing on macOS Catalina? What steps should one take to ensure that the command-line tools and gcc on Catalina are working as expected?
Pass the previous version’s OS X sdk as sysroot, instead of the unversioned sdk.
Command-line tools are failing on macOS Catalina due to incorrect SDK directory.
What steps should one take to ensure that the command-line tools and gcc on Catalina are working as expected? Reference the versioned SDK:
./configure --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
and/or
./configure --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

OSX Sierra Xcode clang libc++ missing qualifier bug

Using:
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.1.0
there are huge numbers of errors introduced in the standard library by a really stupid coding error: an example is here:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/chrono:281:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ratio:256:81: fatal error:
unknown class name 'false_type'; did you mean '::std::false_type'?
template struct __is_ratio : false_type {};
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:278:38: note:
'::std::false_type' declared here
typedef _LIBCPP_BOOL_CONSTANT(false) false_type;
^
The compiler diagnostic is correct, it should read ::std::false_type. I fixed that but then found the same error is repeated over and over again all over the library. The library worked until I decided to use chrono. The bug, however, is not just in chrono.
Does anyone know if this has been fixed?

GCC 4.3.4 and CLANG 3.5 compatiblity

I am building project which based on C++11 so it needed at least GCC 4.7.2 which is not installed on my platform (and I dont have permission to upgrade software on it). So another option is to build the project with Clang and I downloaded and build CLang 3.5. On platform GCC 4.3.4 is preinstalled.
When I compiling the code I got a lot of errors like that one:
[ 88%] Building CXX object system/CMakeFiles/Grappa.dir/tasks/TaskingScheduler.cpp.o
cd /home/frolo/grappa/build/Make+Release/system && /home/frolo/llvm/build/Debug+Asserts/bin/clang++ -DENABLE_RDMA_AGGREGATOR -DGASNET_CONDUIT_IBV -DGASNET_IBV -DGASNET_SEQ -DSHMMAX=1844674407
3709551615 -std=c++11 -Winline -Wno-inline -mno-red-zone -O3 -g -I/home/frolo/grappa/build/Make+Release/third-party/include -I/home/frolo/grappa/build/Make+Release/third-party/include/ibv-condu
it -I/usr/mpi/gcc/openmpi-1.6.4/include -I/home/frolo/grappa/system -I/home/frolo/grappa/system/tasks -o CMakeFiles/Grappa.dir/tasks/TaskingScheduler.cpp.o -c /home/frolo/grappa/system/tasks
/TaskingScheduler.cpp
In file included from /home/frolo/grappa/system/Barrier.cpp:24:
In file included from /home/frolo/grappa/system/Barrier.hpp:26:
In file included from /home/frolo/grappa/system/ConditionVariable.hpp:27:
In file included from /home/frolo/grappa/system/Message.hpp:27:
In file included from /home/frolo/grappa/system/MessageBase.hpp:33:
In file included from /home/frolo/grappa/system/ConditionVariableLocal.hpp:27:
/home/frolo/grappa/system/tasks/TaskingScheduler.hpp:178:25: error: no matching constructor for initialization of 'std::ofstream' (aka 'basic_ofstream<char>')
std::ofstream f(FLAGS_stats_blob_filename);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/fstream:571:7: note: candidate constructor not viable: no known conversion from '::fLS::clstring' (aka 'basic_string<char>') to
'const char *' for 1st argument
basic_ofstream(const char* __s,
^
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/bits/fstream.tcc:916:25: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from '::fLS
::clstring' (aka 'basic_string<char>') to 'const std::basic_ofstream<char>' for 1st argument
extern template class basic_ofstream<char>;
^
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/fstream:556:7: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
basic_ofstream(): __ostream_type(), _M_filebuf()
^
In file included from /home/frolo/grappa/system/IncoherentAcquirer.cpp:24:
In file included from /home/frolo/grappa/system/IncoherentAcquirer.hpp:28:
In file included from /home/frolo/grappa/system/Message.hpp:27:
In file included from /home/frolo/grappa/system/MessageBase.hpp:33:
In file included from /home/frolo/grappa/system/ConditionVariableLocal.hpp:27:
/home/frolo/grappa/system/tasks/TaskingScheduler.hpp:178:25: error: no matching constructor for initialization of 'std::ofstream' (aka 'basic_ofstream<char>')
std::ofstream f(FLAGS_stats_blob_filename);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/fstream:571:7: note: candidate constructor not viable: no known conversion from '::fLS::clstring' (aka 'basic_string<char>') to
'const char *' for 1st argument
basic_ofstream(const char* __s,
^
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../include/c++/4.3/bits/fstream.tcc:916:25: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from '::fLS
::clstring' (aka 'basic_string<char>') to 'const std::basic_ofstream<char>' for 1st argument
extern template class basic_ofstream<char>;
...
It looks like incompatibility between gcc 4.3.4 and clang 3.5, does not it? I am not an experienced user of clang, what can be done here to mend it?
Thank you for any help!
Best,
Alex
Clang 3.5 uses the gcc 4.7 ABI so you should compile with gcc >= 4.7. Alternatively, you can download nightly LLVM/Clang builds in .deb format for Ubuntu/Debian based Linux distros from this site.

How do you fix "implicit instantiation" errors when compiling Mesos on OS X 10.9 Mavericks?

After upgrading to OS X Mavericks, running make in my Mesos build directory results in errors:
google/protobuf/message.cc:130:60: error: implicit instantiation of undefined template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParseFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:108:28: note: template is declared here
class _LIBCPP_TYPE_VIS basic_istream;
^
google/protobuf/message.cc:135:67: error: implicit instantiation of undefined template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParsePartialFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:108:28: note: template is declared here
class _LIBCPP_TYPE_VIS basic_istream;
^
google/protobuf/message.cc:175:16: error: implicit instantiation of undefined template 'std::__1::basic_ostream<char, std::__1::char_traits<char> >'
return output->good();
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:110:28: note: template is declared here
class _LIBCPP_TYPE_VIS basic_ostream;
I started with a clean build directory, re-ran ./bootstrap, and ran cd build && ../configure.
For people who find this page while Googling error messages thrown up by some other software that depends on old versions of Google's protobuf libraries, here's another solution:
Modify the file src/google/protobuf/message.cc and add the line #include <iostream> after the opening comment block, right before all the rest of the #include lines. That one-line change was enough to enable me to compile protoc from protobuf-2.4.1 with the command-line tools from XCode 7.3 on an El Capitan Mac.
OS X Mavericks replaced the gcc command with clang:
$ gcc
clang: error: no input files
However, Mesos currently expects to be compiled with the GNU Compiler Collection. You need to install GCC 4.7 with Homebrew and configure your build directory to use it. To be sure, start with an empty build directory:
# Install GCC 4.7
brew tap homebrew/versions
brew install gcc47
# Configure Mesos build to use GCC
cd /path/to/mesos
rm -rf build
mkdir build
cd build
CC=gcc-4.7 CXX=g++-4.7 ../configure
Then you can run make like before.

Resources