When trying to compile Protobuf-2.6.1 on Solaris 10 SPARC 64, I get:
./google/protobuf/stubs/once.h: In function `void google::protobuf::GoogleOnceInit(google::protobuf::ProtobufOnceType*, void (*)())':
./google/protobuf/stubs/once.h:125: error: cannot convert `google::protobuf::ProtobufOnceType*' to `const volatile google::protobuf::internal::Atomic32*' for argument `1' to `google::protobuf::internal::Atomic32 google::protobuf::internal::Acquire_Load(const volatile google::protobuf::internal::Atomic32*)'
./google/protobuf/stubs/once.h: In function `void google::protobuf::GoogleOnceInit(google::protobuf::ProtobufOnceType*, void (*)(Arg*), Arg*)':
./google/protobuf/stubs/once.h:134: error: cannot convert `google::protobuf::ProtobufOnceType*' to `const volatile google::protobuf::internal::Atomic32*' for argument `1' to `google::protobuf::internal::Atomic32 google::protobuf::internal::Acquire_Load(const volatile google::protobuf::internal::Atomic32*)'
I followed the Official README, ./configure and make.
The compiler version(GCC):
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
I also read the question protobuf generated files does not compile on Solaris SPARC 64 and tried, but it didn't work. That article works on Protobuf-2.4.1, but Protobuf-2.6.1 changes:
2014-10-20 version 2.6.1:
C++
* Added atomicops support for Solaris.
Is there any way to make GCC do force pointer conversion?
I solved the problem according to the github issue #789
The main reason is methioned in the 4th point of this issue. The predefined SOLARIS_64BIT_ENABLED macro takes no effect at all.
The problem can be solved simply by adding -m64 -DSOLARIS_64BIT_ENABLED to CXXFLAGS and CFLAGS. But it's better to do whole modification as the issue suggested.
Related
Replace the default Apple-LLVM with the LLVM 5.0 downloaded from llvm.org.
and compiling, xcode thrown an error:
clang-5.0: error: cannot specify -o when generating multiple output files
Xcode8 is OK.
Thanks.
This is not a Clang 5.0-only issue. I am having the same issue with a custom Clang 3.9.
Xcode 9 has introduced a custom argument that a normal Clang does not support:
The -index-store-path argument does not exist in Clang 5.0 and it gets discarded without any error message. The problem is that its argument, a folder, is not discarded, and Clang considers it as a source file. This leads to the following errors:
cannot specify -o when generating multiple output files (this happens if a -o argument is passed)
error reading '<PATH>' (this can be observed when running the "normalized" version of the clang command, generated via the -### flag)
Source: Facebook/infer: Remove unsupported index-store-path argument from clang commands.
In my custom toolchain based on Clang/CMake/Xcode I use a wrapper around clang in which I just cut off this argument and the folder passed to it and everything works fine.
va_list args = 0;
I found a code in my application as above, and it is compiling properly in following gcc version.
~ $ /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/
bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
But when i compiled the same code in new machine, it is giving issue since the va_list args is initialized with zero. Hope va_list is typedef of something and i removed the initialization of va_list with zero and it is compiled fine in new machine.
But fortunately both old and new machine has same gcc version.
NEW MACHINE GCC VERSION:
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
But i noticed that architecture of two machine is different. Is that causing any issue.
Since stdarg is an standard library. So why it is varying based on architecture?
va_list should never be initialized. It's standard in C and C++ that it is just left uninitialized until va_start() is called.
Your old code was broken. Just remove the =0 regardless of which platform you're on, and try again.
Since stdarg is an standard library. So why it is varying based on architecture?
Yes, it's standard, but it can only be used in the officially supported ways, and initialisation using 0 is not one of those ways.
va_list is not special in that respect, there are plenty of types and functions that are standard, but have implementation variations in their handling of invalid uses. A trivial example is printf(0);, which may silently work and do nothing on some implementations, but crash badly at runtime on others.
Unfortunately there isn't any fool-proof checker for invalid programs that happen to be accepted on your particular platform, nor can there be.
I am trying to get the memory used by another process. From what I've read it seems like I need to use mach_vm_regeion. I found some code on a random forum and tried compiling to make sure I understood how it was working, but I get this error.
error: use of undeclared identifier 'mach_vm_region'
kret = mach_vm_region(task, &address, &size, VM_REGION_BASIC_INFO, (vm_regio...
^
1 error generated.
I am on OS X 10.11.2 compiling using clang++ --std=c++11 file.cpp.
clang --version returns
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
You don't have the correct includes. I find that
#include <mach/mach.h>
#include <mach/mach_vm.h>
works. You also need to change: vm_size_t size to mach_vm_size_t size, which is the type the function expects. Then it compiles and works as expected (when run as root, as the comment suggests).
I am compiling a friend's code on my machine, and I keep getting hit with this error:
$ mpic++ dummy_file_name.cpp
dummy_file_name.cpp: In member function 'bool dummy_name1::dummy_name2::python_convert(const StringMultiArray&, PyObject**)':
dummy_file_name.cpp:430:55:error: cannot convert 'const std::__cxx11::basic_string<char>' to 'const char*' for argument '1' to 'PyObject* PyString_FromString(const char*)'
PyList_SetItem(*dst, i, PyString_FromString(src[i]));
What does this mean? How can I diagnose or treat this issue? I am using the mpic++ compiler. I have tried googling this error but I have not found any fruitful information.
Here is how I built my environment:
brew reinstall gcc --without-multilib
export HOMEBREW_CC=gcc-5
export HOMEBREW_CXX=g++-5
brew install openmpi --build-form-source
brew install llvm --with-clang
It's saying it can't convert const std::__cxx11::basic_string<char> AKA const std::string to const char*. This is a proper error for the compiler to report. As stated above you could fix this by using c_str(), but that would be an awful hack, and maybe violate some component's open source license.
As to why you are getting this error, it may be a mixup with the standard standard c++ libraries. You appear to be using gcc for openmpi and llvm for the link step which is very odd. In addition, you are forcing c++11 for gcc, but not for llvm.
Where did you get these build instructions? You may want to lookup an updated set of instructions.
I'm having the same problem described in this post except I'm using Intel version 12.1.3. (g++'s header <functional> is protected with #ifdef __GXX_EXPERIMENTAL_CXX0X__ which is not defined when icpc is used.)
Instead of using boost::functional, I wanted to install gcc4.7 and use it's std libraries.
In Ubuntu 11.10 I have gcc4.6.1 but I also installed gcc4.7 from the gcc-snapshot package.
Intel has the options -gcc-name, -gxx-name, and -cxxlib.
So originally I compiled with:
-std=c++0x -gcc-name=/usr/lib/gcc-snapshot/bin/gcc -gxx-name=/usr/lib/gcc-snapshot/bin/g++ -cxxlib=/usr/lib/gcc-snapshot/
but I get the error:
icpc: error #10282: file
'/usr/lib/gcc-snapshot/bin/usr/lib/gcc-snapshot/bin/g++' not found,
generated based on '-cxxlib=/usr/lib/gcc-snapshot/'
So then I compiled with:
-std=c++0x -gcc-name=./gcc -gxx-name=./g++ -cxxlib=/usr/lib/gcc-snapshot/.
But I still get the warnings and errors:
Warning #2928: the __GXX_EXPERIMENTAL_CXX0X__ macro is disabled when using GNU version 4.6 with the c++0x option
error: namespace "std" has no member "function"
The warning clearly says it's still using version 4.6. Does anybody know how to get Intel to use the correct libraries?
I've found that if you compile with gcc (or g++) with flags -v -Q you get a list of flags and defines. It might help you see what gcc does so maybe you can use the same -D/-U in icpc. also g++ -E will preprocess without compiling: you can get useful path information from that.