macosx thread explicitly marked deleted - multithreading

I'm building an application with C++11 threads, but I can't seem to get it to work with clang++ on MacOSX 10.9. Here is the simplest example I can find that causes the issues:
#include <thread>
#include <iostream>
class Functor {
public:
Functor() = default;
Functor (const Functor& ) = delete;
void execute () {
std::cerr << "running in thread\n";
}
};
int main (int argc, char* argv[])
{
Functor functor;
std::thread thread (&Functor::execute, std::ref(functor));
thread.join();
}
This compiles and runs fine on Arch Linux using g++ (version 4.9.2) with the following command-line:
$ g++ -std=c++11 -Wall -pthread test_thread.cpp -o test_thread
It also compiles and runs fine using clang++ (version 3.5.0, also on Arch Linux):
$ clang++ -std=c++11 -Wall -pthread test_thread.cpp -o test_thread
But fails on MacOSX 10.9.5, using XCode 6.1 (regardless of whether I include the -stdlib=libc++ option):
$ clang++ -std=c++11 -Wall -pthread test_thread.cpp -o test_thread
In file included from test_thread.cpp:1:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:332:5: error: attempt to use a deleted function
__invoke(_VSTD::move(_VSTD::get<0>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:342:5: note: in instantiation of function template specialization
'std::__1::__thread_execute<void (Functor::*)(), std::__1::reference_wrapper<Functor> , 1>' requested here
__thread_execute(*__p, _Index());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:354:42: note: in instantiation of function template specialization
'std::__1::__thread_proxy<std::__1::tuple<void (Functor::*)(), std::__1::reference_wrapper<Functor> > >' requested here
int __ec = pthread_create(&__t_, 0, &__thread_proxy<_Gp>, __p.get());
^
test_thread.cpp:19:15: note: in instantiation of function template specialization 'std::__1::thread::thread<void (Functor::*)(), std::__1::reference_wrapper<Functor> , void>'
requested here
std::thread thread (&Functor::execute, std::ref(functor));
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:1001:5: note: '~__nat' has been explicitly marked deleted
here
~__nat() = delete;
^
1 error generated.
I can't figure out how to get around this, it seems like a compiler bug to me. For reference, the version of clang on that Mac is:
$ clang++ --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Any ideas what it is I'm doing wrong?
Thanks!
Donald.

The standard does not require the std::thread constructor - or the similar std::async for that matter - to unwrap a reference_wrapper when passed as the first argument with a pointer-to-member-function the way std::bind does. Pass a pointer to Functor instead of a reference_wrapper. (See Library Active Issues list DR2219.)

Related

can't compile OpenFOAM v1912 with intel icc and intelmpi

! UPDATE on 28 Feb, 2020:
The problem is solved. please refer to :https://develop.openfoam.com/Development/openfoam/issues/1608
Summary
I'm new to OpenFOAM and I'm trying to compile OpenFOAM-v1912 using Icc and IntelMPI, only to find the following confusing error. It seems like an error in codes. But it just makes no sense, because I have successfully compiled it with gcc(v4.8.5) and openmpi(1.10.7), and it worked just fine. I'd be more than delighted to hear any suggestions. Ideas about what the problem might be will also be of great help. THANKS A LOT!
wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
Steps to reproduce
I edited OpenFOAM-v1912/etc/bashrc from
...
export WM_COMPILER=Gcc
...
export WM_MPLIB=OPENMPI
...
to
...
export WM_COMPILER=Icc
...
export WM_MPLIB=INTELMPI
...
and I got "ld: cannot find -lmpi" error so I edit OpenFOAM-v1912/wmake/rules/General/Icc/c++
CC = icpc -std=c++11
to
CC = mpiicc -std=c++11
then under directory OpenFOAM-v1912/ , I ran
./Allwmake
What I've tried
Compiling with $WM_LABEL_SIZE=64
But it just seemed irrelevant and it got stuck on building libscotch. Doesn't seem to help at all.
Details of the error from the promts:
wmake reactingEulerFoam/phaseSystems
wmake reactingEulerFoam/interfacialModels
wmake reactingEulerFoam/interfacialCompositionModels
wmake reactingEulerFoam/derivedFvPatchFields
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseSystem
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseCompressibleTurbulenceModels
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseSystem
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels
wmake field
mpiicc -std=c++11 -fp-trap=common -fp-model precise -DOPENFOAM=1912 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-unknown-pragmas -diag-disable 327,654,1125,1292,2289,2304,11062,11074,11076 -O3 -DNoRepository -ftemplate-depth-100 -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/finiteVolume/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fileFormats/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/surfMesh/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/meshTools/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/sampling/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/distributionModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/turbulenceModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/incompressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/solidThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/chemistryModel/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/reactionThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/specie/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fvAgglomerationMethods/pairPatchAgglomeration/lnInclude -IlnInclude -I. -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OSspecific/POSIX/lnInclude -fPIC -c wallBoundedStreamLine/wallBoundedStreamLine.C -o /share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o
wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
operand types are: Foam::cell == const Foam::label
cell() == mesh().faceOwner()[face()]
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/particle.H(70): note: this candidate was rejected because arguments do not match
bool operator==(const particle&, const particle&);
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/labelBits.H(123): note: this candidate was rejected because function is not visible
inline friend bool operator==(const labelBits& a, const labelBits& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/objectMapI.H(85): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const objectMap& a, const objectMap& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/triFaceI.H(406): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const triFace& a, const triFace& b)
^
(followed by lots of rejected candidates)
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
wallBoundedStreamLine/wallBoundedParticleTemplates.C(138): error: no operator "=" matches these operands
operand types are: Foam::cell = Foam::label
cell() = nbrCelli;
^
detected during:
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
compilation aborted for wallBoundedStreamLine/wallBoundedStreamLine.C (code 2)
make: *** [/share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o] Error 2
Environment information
OpenFOAM: v1912 (codes from https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz)
ThirdParty from https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz
Intel suite: parallel_studio_xe_2020_cluster_edition
Intel icc: icc (ICC) 19.1.0.166 20191121
Intel MPI lib: for Linux* OS, Version 2019 Update 6 Build 20191024
OS Kernel: Linux version 3.10.0-1062.el7.x86_64 (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) )
OS: CentOS 7.7.1908
CPU: 72 * Intel(R) Xeon(R) Gold 6240 CPU # 2.60GHz
Solution
The problem is solved! Please refer to https://develop.openfoam.com/Development/openfoam/issues/1608.

Why does a program using sqrt compile with gcc without specifying a math library

given the following program:
#include <math.h>
#include <stdio.h>
int
main(void)
{
double x = sqrt(2);
printf("The square root of two is %f\n", x);
return 0;
}
and compiling with:
gcc calc.c -o calc
succeeds? why doesn't it require -lm or /usr/lib/blah/libm.so.x
inspecting the binary object with ldd produces:
linux-vdso.so.1 (0x00007fff4f5e5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feeffd1b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fef000e1000
No libm is referenced. However, if I look at the libc.so.6 library or the ld-linux-x86-64.so.2 library using nm -D, no sqrt function is in those libraries.
What's going on here? Is gcc magically including a default set of common functions or something else?
No, the gcc compiler knows that sqrt(2) is a constant value and just calculates the value at compile time.
To trigger a use of the sqrt() library function, use code like this:
volatile double y = 2;
double x = sqrt(y);
One could also use the -ffreestanding gcc option, but this is not recommeneded.

context sharing in FreeGLUT under Linux with xorg

I am trying to use OpenGL with shared context (because of sharing textures between windows) via FreeGLUT library... It work fine, I can share textures, but i failed on the end of program or during windows closing by mouse...
I have cerated the code which emulate the problem: (http://pastie.org/9437038)
// file: main.c
// compile: gcc -o test -lglut main.c
// compile: gcc -o test -lglut -DTIME_LIMIT main.c
#include "GL/freeglut.h"
#include <unistd.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
int winA, winB, winC;
int n;
glutInit(&argc, argv);
glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE , GLUT_ACTION_CONTINUE_EXECUTION);
//glutSetOption(GLUT_RENDERING_CONTEXT, GLUT_USE_CURRENT_CONTEXT);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
winA = glutCreateWindow("Test A");
glutSetOption(GLUT_RENDERING_CONTEXT, GLUT_USE_CURRENT_CONTEXT);
winB = glutCreateWindow("Test B");
winC = glutCreateWindow("Test C");
printf("loop\n");
#ifdef TIME_LIMIT
for (n=0;n<50;n++)
{
glutMainLoopEvent();
usleep(5000);
}
#else //TIMELIMIT
glutMainLoop();
#endif // TIME_LIMIT
printf("Destroy winC\n");
glutDestroyWindow(winC);
printf("Destroy winB\n");
glutDestroyWindow(winB);
printf("Destroy winA\n");
glutDestroyWindow(winA);
printf("Normal end\n");
return 0;
}
Output:
loop
X Error of failed request: GLXBadContext
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 4 (X_GLXDestroyContext)
Serial number of failed request: 113
Current serial number in output stream: 114
Segmentation fault
output with TIME_LIMIT:
loop
Destroy winC
Destroy winB
Destroy winA
Segmentation fault
Without calling glutSetOption(GLUT_RENDERING_CONTEXT, GLUT_USE_CURRENT_CONTEXT);, it works well.
Do anybody have idea what am I doing bad?
The option GLUT_USE_CURRENT_CONTEXT does not create shared contexts. It just means that the same GL context is used for all windows. You only have one GL conxtext, and destroy it when you first destroy a window which uses that, so the other destruction calls fail. None of the GLUT implementations I'm aware of actually supports GL context sharing.
GLUT_USE_CURRENT_CONTEXT is more like a hack (and it is nor part of the GLUT specification anyway), and not really a well-implemented. It could use some reference counting to destroy the context not before the last window using it is destroyed, but that is simply not the case.

G++: linker doesnt seem to link correctly

I try to compile a program I have to control a DAQ device. In Windows, g++ compile and links OK, but in Linux it doesn't. The linker (called by G++) displays:
g++ -Wall -o "acelerar-30-0" "acelerar-30-0.cpp" (en el directorio: /home/poly/)
/tmp/ccRLpB4q.o: In function `main':
acelerar-30-0.cpp:(.text+0x429): undefined reference to `AdxInstantAoCtrlCreate'
collect2: ld returned 1 exit status
Ha fallado la compilaciĆ³n.
The cpp file is this (cut):
include stdlib.h
include stdio.h
include math.h
include "compatibility.h"
include "bdaqctrl.h"
include "comunes.h"
using namespace Automation::BDaq;
define deviceDescription L"USB-4704,BID#0"
int32 channelStart = 0;
int32 channelCount = 1;
double voltaje[0];
int32 modo;
int32 ms;
int main(int argc, char* argv[])
{
if (argc!=3)
salidaerror(argv[0],1);
channelStart = atoi(argv[1]);
ms = atoi(argv[2]);
if (channelStart<0||channelStart>1||ms<10)
salidaerror(argv[0],1);
ErrorCode ret = Success;
InstantAoCtrl * instantAoCtrl = AdxInstantAoCtrlCreate();
...
I have been several hours on this, and can't find the answer. The SDK is for Debian/Ubuntu, and it has the same code for Linux and Windows.
Any hints? Thanks
EDIT: Removed some marks as the formatting was incorrect
In my (limited) experience, typical gcc behavior will require that you specify the library containing that function as an argument on the command line like so:
-lsome_library
This is required even if the library is in your library path (additional library paths can be specified with -L). Find the appropriate library file containing that function and use its filename minus extensions and leading "lib" in the argument format above.

Compiling/Linking CUDA and CPP Source Files

I am working through a sample program that uses both C++ source code as well as CUDA. This is the essential content from my four source files.
matrixmul.cu (main CUDA source code):
#include <stdlib.h>
#include <cutil.h>
#include "assist.h"
#include "matrixmul.h"
int main (int argc, char ** argv)
{
...
computeGold(reference, hostM, hostN, Mh, Mw, Nw); //reference to .cpp file
...
}
matrixmul_gold.cpp (C++ source code, single function, no main method):
void computeGold(float * P, const float * M, const float * N, int Mh, int Mw, int Nw)
{
...
}
matrixmul.h (header for matrixmul_gold.cpp file)
#ifndef matrixmul_h
#define matrixmul_h
extern "C"
void computeGold(float * P, const float * M, const float * N, int Mh, int Mw, int Nw);
#endif
assist.h (helper functions)
I am trying to compile and link these files so that they, well, work. So far I can get matrixmul_gold.cpp compiled using:
g++ -c matrixmul_gold.cpp
And I can compile the CUDA source code with out errors using:
nvcc -I/home/sbu/NVIDIA_GPU_Computing_SDK/C/common/inc -L/home/sbu/NVIDIA_GPU_Computing_SDK/C/lib matrixmul.cu -c -lcutil_x86_64
But I just end up with two .O files. I've tried a lot of different ways to link the two .O files but so far it's a no-go. What's the proper approach?
UPDATE: As requested, here is the output of:
nm matrixmul_gold.o matrixmul.o | grep computeGold
nm: 'matrixmul.o': No such file
0000000000000000 T _Z11computeGoldPfPKfS1_iii
I think the 'matrixmul.o' missing error is because I am not actually getting a successful compile when running the suggested compile command:
nvcc -I/home/sbu/NVIDIA_GPU_Computing_SDK/C/common/inc -L/home/sbu/NVIDIA_GPU_Computing_SDK/C/lib -o matrixmul matrixmul.cu matrixmul_gold.o -lcutil_x86_64
UPDATE 2: I was missing an extern "C" from the beginning of matrixmul_gold.cpp. I added that and the suggested compilation command works great. Thank you!
Conventionally you would use whichever compiler you are using to compile the code containing the main subroutine to link the application. In this case you have the main in the .cu, so use nvcc to do the linking. Something like this:
$ g++ -c matrixmul_gold.cpp
$ nvcc -I/home/sbu/NVIDIA_GPU_Computing_SDK/C/common/inc \
-L/home/sbu/NVIDIA_GPU_Computing_SDK/C/lib \
-o matrixmul matrixmul.cu matrixmul_gold.o -lcutil_x86_64
This will link an executable binary called matrimul from matrixmul.cu, matrixmul_gold.o and the cutil library (implicitly nvcc will link the CUDA runtime library and CUDA driver library as well).

Resources