! 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.
Related
I am really new on Linux drivers and I am trying to Compile Linux kernel 2.6,
I did these steps so far on my Linux 4.0
1)
I got Latest Linux kernel code for 2.x.y.z and Extract tar (.tar.bz3) file
2) Installed gcc,
apt-get install gcc
3)Try to make below but all of them occurred with error:
make menuconfig
make xconfig
make gconfig
Error:
root#kiarash-VirtualBox:~/Desktop/linux-2.6.9# make gconfig
HOSTCC scripts/basic/fixdep
scripts/basic/fixdep.c: In function ‘traps’:
scripts/basic/fixdep.c:368:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
if (*(int *)test != INT_CONF) {
^
scripts/basic/fixdep.c:370:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
*(int *)test);
^
HOSTCC scripts/basic/split-include
scripts/basic/split-include.c: In function ‘main’:
scripts/basic/split-include.c:133:6: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result]
fgets(old_line, buffer_size, fp_target);
^
HOSTCC scripts/basic/docproc
*
* Unable to find the GTK+ installation. Please make sure that
* the GTK+ 2.0 development package is correctly installed...
* You need gtk+-2.0, glib-2.0 and libglade-2.0.
*
HOSTCC scripts/kconfig/conf.o
scripts/kconfig/conf.c: In function ‘conf_string’:
scripts/kconfig/conf.c:164:20: warning: variable ‘help’ set but not used [-Wunused-but-set-variable]
const char *def, *help;
^
scripts/kconfig/conf.c: In function ‘conf_sym’:
scripts/kconfig/conf.c:198:6: warning: variable ‘type’ set but not used [-Wunused-but-set-variable]
int type;
^
scripts/kconfig/conf.c: In function ‘conf_choice’:
scripts/kconfig/conf.c:273:6: warning: variable ‘type’ set but not used [-Wunused-but-set-variable]
int type;
^
scripts/kconfig/conf.c: In function ‘conf_askvalue’:
scripts/kconfig/conf.c:94:3: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result]
fgets(line, 128, stdin);
^
scripts/kconfig/conf.c: In function ‘conf_choice’:
scripts/kconfig/conf.c:350:4: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result]
fgets(line, 128, stdin);
^
make[1]: *** No rule to make target 'scripts/kconfig/.tmp_gtkcheck', needed by 'scripts/kconfig/gconf.o'. Stop.
Makefile:429: recipe for target 'gconfig' failed
make: *** [gconfig] Error 2
Please help me to undrestand!
write below in your terminal in order to install gtk2.0 and libgtk2.0-dev
sudo apt-get install gtk2.0
sudo apt-get install build-essential libgtk2.0-dev
When I compile my code with
gfortran -O2 calpuff.for -o calpuff.exe
The following code:
REAL FUNCTION R1MACH (I)
C***BEGIN PROLOGUE R1MACH
C ...
real SMALL(2)
real LARGE(2)
real RIGHT(2)
real DIVER(2)
real LOG10(2)
c --- Set up for IBM PC: declare as reals ..........(DGS)
C
REAL RMACH(5)
SAVE RMACH
C
EQUIVALENCE (RMACH(1),SMALL(1))
EQUIVALENCE (RMACH(2),LARGE(1))
EQUIVALENCE (RMACH(3),RIGHT(1))
EQUIVALENCE (RMACH(4),DIVER(1))
EQUIVALENCE (RMACH(5),LOG10(1))
C ...
DATA SMALL(1) / 1.18E-38 /
DATA LARGE(1) / 3.40E+38 /
DATA RIGHT(1) / 0.595E-07 /
DATA DIVER(1) / 1.19E-07 /
DATA LOG10(1) / 0.30102999566 /
C ...
C***FIRST EXECUTABLE STATEMENT R1MACH
IF (I .LT. 1 .OR. I .GT. 5) CALL XERMSG ('SLATEC', 'R1MACH',
+ 'I OUT OF BOUNDS', 1, 2)
C
R1MACH = RMACH(I)
RETURN
C
END
Result shows in the following error:
calpuff.for: In function ‘r1mach’:
calpuff.for:58522: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables
compilation terminated.
Line 58522 corresponds to the first line of the code shown.
Why does this error occur?
Some information about my compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)
This is a known compiler bug in gfortran, see here and here. This bug has been fixed in 2007.
Please update to a more recent version of gfortran.
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.)
I'm willing to bet I'm not configuring it right, but it's not brief on how I need to for wxWidgets_3_0
I get the following error:
$ make
/home/Bill/WX_3_0_BRANCH/build-debug/bk-deps g++ -c -o basedll_appbase.o -D__WXM SW__ -DWXBUILDING -I/home/Tom/WX_3_0_BRANCH/build-debug/src/tiff/libtiff -I ../src/tiff/libtiff -I../src/jpeg -I../src/png -I../src/zlib -I../src/regex -I.. /src/expat/lib -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -Wall -Wundef -W unused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -D_FILE_OFFSET_BITS =64 -I/home/Tom/WX_3_0_BRANCH/build-debug/lib/wx/include/msw-unicode-3.0 -I../in clude -O2 -fno-strict-aliasing ../src/common/appbase.cpp
In file included from ../src/common/appbase.cpp:42:0:
../include/wx/filename.h: In static member function ‘static wxUniChar wxFileName ::GetPathSeparator(wxPathFormat)’:
../include/wx/filename.h:473:43: error: ambiguous overload for ‘operator[]’ (ope rand types are ‘wxString’ and ‘unsigned int’)
{ return GetPathSeparators(format)[0u]; }
In file included from ../include/wx/memory.h:15:0,
from ../include/wx/object.h:19,
from ../include/wx/list.h:32,
from ../src/common/appbase.cpp:30:
../include/wx/string.h:1544:15: note: wxUniChar wxString::operator[](int) const
wxUniChar operator[](int n) const
^
../include/wx/string.h:1546:15: note: wxUniChar wxString::operator[](long int) c onst
wxUniChar operator[](long n) const
^
../include/wx/string.h:1548:15: note: wxUniChar wxString::operator[](size_t) con st
wxUniChar operator[](size_t n) const
^
../include/wx/string.h:1556:18: note: wxUniCharRef wxString::operator[](int)
wxUniCharRef operator[](int n)
^
../include/wx/string.h:1558:18: note: wxUniCharRef wxString::operator[](long int )
wxUniCharRef operator[](long n)
^
../include/wx/string.h:1560:18: note: wxUniCharRef wxString::operator[](size_t)
wxUniCharRef operator[](size_t n)
^
Makefile:28650: recipe for target 'basedll_appbase.o' failed
make: *** [basedll_appbase.o] Error 1
This is what's in the makefile on that line:
basedll_appbase.o: $(srcdir)/src/common/appbase.cpp $(BASEDLL_ODEP)
$(CXXC) -c -o $# $(BASEDLL_CXXFLAGS) $(srcdir)/src/common/appbase.cpp
This is a known bug, but I thought it affected only wxGTK and hence it had a low priority (because subset of people using wxGTK under Cygwin is vanishingly small). If it affects wxMSW as well, it would be nice to fix it, especially as it shouldn't be difficult, and we'll try to do it for the next 3.0.1 release.
Seems that long, unsigned int, and size_t are all expected to exist as different function signatures
So the fix for this case was to add a cast of size_t to any ambiguous overload errors with 0u or 1u.
Here's on example: in the filename.h I edited its source code:
// get the canonical path separator for this format
static wxUniChar GetPathSeparator(wxPathFormat format = wxPATH_NATIVE)
{ return GetPathSeparators(format)[0u]; }
to
// get the canonical path separator for this format
static wxUniChar GetPathSeparator(wxPathFormat format = wxPATH_NATIVE)
{ return GetPathSeparators(format)[(size_t)0u]; }
The second thing I had to do was configure for my 64 bit windows
../configure --host=i686-w64-mingw32 --build=i686-pc-cygwin
I tried writing compiling and running my first nimrod program a fizzbuzz.
Nimrod is installed from git and version is.
[sayth nimrod]$ nimrod --version
Nimrod Compiler Version 0.9.4 (2014-04-28) [Linux: amd64]
Copyright (c) 2006-2014 by Andreas Rumpf
So here is a fizzbuzz
proc fizzBuzz(x, y: int) =
for i in x .. y:
if i mod 15 == 0:
echo("FizzBuzz")
elif i mod 3 == 0:
echo("Fizz")
elif i mod 5 == 0:
echo("Buzz")
else:
echo(i)
I compiled to c (is there a better option?) and it appeared ok to me.
[sayth nimrod]$ nimrod c fizzbuzz.nim
config/nimrod.cfg(37, 2) Hint: added path: '/home/sayth/.babel/pkgs/' [Path]
Hint: used config file '/home/sayth/Nimrod/config/nimrod.cfg' [Conf]
Hint: system [Processing]
Hint: fizzbuzz [Processing]
fizzbuzz.nim(1, 5) Hint: 'fizzbuzz.fizzBuzz(x: int, y: int)' is declared but not used [XDeclaredButNotUsed]
gcc -c -w -I/home/sayth/Nimrod/lib -o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.c
gcc -c -w -I/home/sayth/Nimrod/lib -o /home/sayth/Scripts/nimrod/nimcache/stdlib_system.o /home/sayth/Scripts/nimrod/nimcache/stdlib_system.c
gcc -o /home/sayth/Scripts/nimrod/fizzbuzz /home/sayth/Scripts/nimrod/nimcache/stdlib_system.o /home/sayth/Scripts/nimrod/nimcache/fizzbuzz.o -ldl
Hint: operation successful (8181 lines compiled; 1.065 sec total; 13.138MB) [SuccessX]
But running it produces no output. Is there something I am doing wrong?
[sayth nimrod]$ ./fizzbuzz
[sayth nimrod]$
You simply forgot to call it. Note the compiler hint:
fizzbuzz.nim(1, 5) Hint: 'fizzbuzz.fizzBuzz(x: int, y: int)' is declared but not used [XDeclaredButNotUsed]
And no, your best option is compiling to C. There may be an LLVM backend in the future, but the general opinion is that it is more trouble than it is worth. Intermediate C output is more portable (gcc runs in many more plataforms than LLVM) and you can chose the compiler that can best optimize your code.