cmake g++-5: c++11 and OpenMP support - c++11

On a Mac pro I have installed g++
brew install gcc --without-multilib
I have then g++-5 installed in /usr/local/bin
The compiler supports OpenMP and also c++11
The following code compiles and runs as expected:
#include <iostream>
int main(int argc, const char **argv)
{
auto i = 42;
int arr[] = {1,2,3,4,5};
for(int& e : arr)
{
e = e*e;
}
#pragma omp parallel
{
std::cout << "Hello OpenMP!\n";
}
return 0;
}
compiling:
g++-5 -fopenmp -std=c++11 omp_code.cpp -o omp_executable
However,
cmake -DCMAKE_CXX_COMPILER=g++-5 -DCMAKE_C_COMPILER=gcc-5 ..
tells me that Could NOT find OpenMP (missing: OpenMP_CXX_FLAGS)
and The compiler /usr/local/bin/g++-5 has no C++11 support
For OpenMP I use FIND_PACKAGE(OpenMP) and for c++11 I use
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
Any idea how to solve this? A workaround was just to put the c++11 and -fopenmp flags even if the checks fail. That worked fine. However, I would like to have a better solution.

Related

Shadow memory and fPie error when running code with thread sanitizer?

The following code sample is compiled with the subsequent command line input
#include <pthread.h>
#include <stdio.h>
#include <string>
#include <map>
typedef std::map<std::string, std::string> map_t;
void *threadfunc(void *p) {
map_t& m = *(map_t*)p;
m["foo"] = "bar";
return 0;
}
int main() {
map_t m;
pthread_t t;
pthread_create(&t, 0, threadfunc, &m);
printf("foo=%s\n", m["foo"].c_str());
pthread_join(t, 0);
}
Command line input:
g++ thread.cpp -fsanitize=thread -fPIE -pie -lpie -g
It compiles fine, but when the code is run there are runtime errors.
FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x56167ae3b000 < 0x7cf000000000)
FATAL: Make sure to compile with -fPIE and to link with -pie.
I am running this with a version of g++ that has fSanitize so I am unsure about where the source of the problem is?
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
GCC is too old for Linux kernel used in your RedHat. Due to the mapped address 0x56167ae3b000 I guess the kernel version is 4.1+ (or backported from the kernel version 4.1+) that maps binaries at 0x550000000000. This mapped address is supported by GCC starting from the version 7.1.1. Please try to add the compiler flag -static-libtsan. If it does not help then you need to upgrade your compiler.

Linking libusb in Mac OS X

I have this very simple piece of code that I'm trying to compile. I'm fairly new to GCC from the command line, so please forgive me. I've tried a quite few different things with GCC, but I'm still unable to get it to compile. I do have libusb installed. How can I get this piece of code to compile?
Libusb:
anything:usb mymac$ brew list libusb
/usr/local/Cellar/libusb/1.0.9/include/libusb-1.0/libusb.h
/usr/local/Cellar/libusb/1.0.9/lib/libusb-1.0.0.dylib
/usr/local/Cellar/libusb/1.0.9/lib/pkgconfig/libusb-1.0.pc
/usr/local/Cellar/libusb/1.0.9/lib/ (2 other files)
anything:usb mymac$
GCC attempts (all failed):
gcc -o xout usbtest.c
gcc -o xout usbtest.c -lusb-1.0
gcc -L/usr/local/Cellar/libusb/1.0.9/lib -o xout usbtest.c -lusb-1.0
Error for all attempts:
usbtest.c:3:10: fatal error: 'libusb.h' file not found
#include <libusb.h>
Code:
#include <stdio.h>
#include <stdlib.h>
#include <libusb.h>
int main(int argc, const char * argv[])
{
libusb_device **devs;
libusb_context *context = NULL;
size_t list;
//size_t i;
int ret;
ret = libusb_init(&context);
if(ret < 0)
{
perror("libusb_init");
exit(1);
}
list = libusb_get_device_list(context, &devs);
printf("There are %zd devices found\n", list);
return 0;
}
So I had a similar issue, for some reason gcc doesnt include /usr/local/lib in its default search path on OS X. The quick fix is to add:
-lusb-1.0
to the gcc commands and it should compile.
You are not telling gcc where to look for the header files. This is done by the -I option on the gcc command line for compiling.
e.g.
gcc -I /usr/local/include -o xout usbtest.c
I think Homebrew does provide a symbolic link frominside the Cellar to /usr/local

Not able to use srand48() after changing to c++ 11

Why am I not able to compile my code to c++ 11 and use the srand48 function?
I have a program where I play around with some matrices.
The problem is that when I compile the code with the -std=c++0x flag.
I want to use some c++11 only functions and this is my approach to do so.
It compiles without any problems if I do not specify the c++ version. Like this:
g++ -O2 -Wall test.cpp -o test -g
Please correct me if I have misunderstood what the mentioned flag does.
I run my code on a Windows 7 64-bit machine and compile through cygwin. I use g++ version 4.5.3 (GCC). Please comment if more information is required.
For some unknown reason (even to myself) then all my code is written in one compilation unit.
If the error is caused by a structural error then you should also feel free to point it out. :)
I receive the following errors:
g++ -std=c++0x -O2 -Wall test.cpp -o test -g
test.cpp: In function ‘void gen_mat(T*, size_t)’:
test.cpp:28:16: error: there are no arguments to ‘srand48’ that depend on a template parameter, so a declaration of ‘srand48’ must be available
test.cpp:28:16: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
test.cpp:33:28: error: there are no arguments to ‘drand48’ that depend on a template parameter, so a declaration of ‘drand48’ must be available
Here is a sub of my code, it generates the errors shown above.
#include <iostream>
#include <cstdlib>
#include <cassert>
#include <cstring>
#include <limits.h>
#include <math.h>
#define RANGE(S) (S)
// Precision for checking identity.
#define PRECISION 1e-10
using namespace std;
template <typename T>
void gen_mat(T *a, size_t dim)
{
srand48(dim);
for(size_t i = 0; i < dim; ++i)
{
for(size_t j = 0; j < dim; ++j)
{
T z = (drand48() - 0.5)*RANGE(dim);
a[i*dim+j] = (z < 10*PRECISION && z > -10*PRECISION) ? 0.0 : z;
}
}
}
int main(int argc, char *argv[])
{
}
Regards Kim.
This is the solution that solved the problem for me:
First n.m. explained that srand() can not be used when compiling with -std=c++0x.
The correct flag to use is -std=gnu++11 however it require g++ version 4.7+
Therefore, the solution for me was to compile my code with -std=gnu++0x
The compile command = g++ -O2 -Wall test.cpp -o test -g -std=gnu++0x
If you explicitly set -stc=c++03 you will get the same error. This is because drand48 and friends are not actually a part of any C++ standard. gcc includes these functions as an extension, and disables them if standard behaviour is requested.
The default standard mode of g++ is actually -std=gnu++03. You may want to use -std=gnu++11 instead of -std=c++0x, or pass -U__STRICT_ANSI__ to the compiler.

Compiling C++ that uses Boost::mpi with Xcode 4

I'm trying to run the following simple example from Xcode4:
#include <boost/mpi/environment.hpp>
#include <boost/mpi/communicator.hpp>
#include <iostream>
namespace mpi = boost::mpi;
int main(int argc, char* argv[])
{
mpi::environment env(argc, argv);
mpi::communicator world;
std::cout << "I am process " << world.rank() << " of " << world.size()
<< "." << std::endl;
return 0;
}
I've added libboost_mpi and libboost_serialization to Xcode, and compiling using the default LLVM returns :
/usr/local/include/boost/mpi/communicator.hpp:1329:9: error: call to
implicitly-deleted copy constructor of 'boost::mpi::communicator'
: comm(comm), source(source), tag(tag), ia(comm), value(value)
^ ~~~~
However, I can compile and run using
mpic++ -I/usr/local/include main.cpp -L/usr/local/lib
-lboost_mpi -lboost_serialization
Although mpic++ seems to be calling through to LLVM:
$ mpic++
i686-apple-darwin11-llvm-g++-4.2: no input files
Anyways, I tried adding mpic++ as a compiler option in Xcode 4. I can run
$ sudo opensnoop -n Xcode | grep mpicc.xcspec
and see that the spec file is being loaded by Xcode, but I don't see any MPICC option. My spec file is fairly simple:
/**
Xcode Compiler Specification for MPICC
*/
{ Type = Compiler;
Identifier = com.apple.compilers.mpicc;
BasedOn = com.apple.compilers.gcc.4_2;
Name = “MPICC”;
Version = “Default”;
Description = “MPI GNU C/C++ Compiler 4.0″;
ExecPath = “/usr/local/bin/mpicc”;
PrecompStyle = pch;
}
and it's stored in
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/LLVM GCC 4.2.xcplugin/Contents/Resources/mpicc.xcspec
So this works:
link binary with:
libmpi_cxx.dylib
libmpi.dylib
libboost_mpi.dylib
libboost_serialization.dylib
Change compiler (under build options) to LLVM GCC 4.2 (hinted at by running mpic++ directly, which reports that it's using llvm gcc 4.2 internally)
Under targets, build phases, compile sources, add the compiler option "-lm" to report that you need to link with libm. Credit to #pyCthon for pointing out mpic++ --showme:link which revealed the final library that was allowing it to build successfully from the command line

Why does GCC 4.2.1 ignore #pragma GCC diagnostic ignored "-Wcast-qual" under certain conditions?

Here is my test program:
#include <stdio.h>
#pragma GCC diagnostic ignored "-Wcast-qual"
static void proc(char *buf)
{
printf("buf=%p\n",buf);
}
int main(int argc,char **argv)
{
const char *cbuf;
char *buf = (char *)cbuf;
proc(buf);
return(0);
}
Here is my compile:
$ g++ -Wcast-qual x.cpp
x.cpp: In function ‘int main(int, char**)’:
x.cpp:13: warning: cast from type ‘const char*’ to type ‘char*’ casts away constness
$
And here is the compile without the -Wcast-qual:
$ g++ x.cpp
$
I've used #pragma GCC diagnostic ignored in other places of my code without problems. Here it is not working. Can somebody tell me why?
It's a compiler bug on the Mac. GCC 4.7.2 on Linux does not have this problem. Neither does clang++. On the Mac you should try to use clang++, not g++.
Apple should update its compiler.

Resources