Foam::CECCellToFaceStencil::CECCellToFaceStencil(. ..) is private
I'm just trying to compile OpenFOAM-1.6 and I get such error message (many,may times):
lnInclude/CECCellToFaceStencil.H: In constructor ‚Foam::centredCECCellToFaceStencilObject::centredC ECCellToFaceStencilObject(const Foam::fvMesh&)‚:
lnInclude/CECCellToFaceStencil.H:57: error: ‚Foam::CECCellToFaceStencil::CECCellToFaceStencil( const Foam::CECCellToFaceStencil&)‚ is private
lnInclude/centredCECCellToFaceStencilObject.H:69: error: within this context
As this is clearly source code bug - could anyone let me know what should be modified?
This is a compiler 'feature'. Gcc 4.3.3 does not have any problems with it, older versions do.
As a workaround do an explicit cast:
Thank you very much for your answer. As you sure it should solve the problem? To be completely sure: in file src/finiteVolume/lnInclude/CFCCellToFaceStencil.H replace line 70, which is:
extendedCentredCellToFaceStencil( static_cast<const cellToFaceStencil&>(CECCellToFaceStencil(mesh)))
I did that and it crashes exactly like it did before.
And you're right, gcc is 4.1. But I'd rather use system one than install another one and maintain it afterwards. And updating the system is out of question unfortunately.
could you confirm that all files in folder OpenFOAM-1.6.x/src/finiteVolume/fvMesh/extendedStencil/cellToFace/MeshObjects/ should be modified using the same syntax ? I've been struggling with this problem for a while and I would really appreciate if you could clarify this patch.
As far as I see the topic was reported on the gcc-list (see the "Copy constructor access check while initializing a reference" section of the link provided by the reporter for the detailed description of the topic):
I would be very interested too if anyone tries a workaround written in the link provided by the poster of the email above (create a member function that returns a const reference to *this). Shall try myself but next week at the earliest...
yes, you'll have to patch all the other files in a similar way. Did that patch fix your CFCCellToFaceStencil.H problem? (warning, there are a lot of files with similar names)
interesting - I'll have a look.
Guys, thanks for your answers and suggestions.
I did not patch all files yet but will do today.
I tried to change the following files in src/finiteVolume/fvMesh/extendedStencil/cellToFace/MeshObjects:
and pureUpwindCFCCellToFaceStencilObject.H (I didn't change files upwind*CellToFaceStencilObject.H since I'm not sure what to do),
and I still had the same errors.
Since I really wanted to get this to work, so I tried something that may seem silly to all of you, especially OF developpers (I must admit that I do NOT know what I was doing, but this might give you some hints what could be the problem). Here is what I did:
in file src/finiteVolume/fvMesh/extendedStencil/cellToFace/fullStencils/CECCellToFaceStencil.H, moved "public:" several lines above to change the copy constructor from private to public, i.e.
//- Disallow default bitwise copy construct
//- Disallow default bitwise assignment
void operator=(const CECCellToFaceStencil&);
Same thing for CFCCellToFaceStencil.H, CPCCellToFaceStencil.H, and FECCellToFaceStencil.H in the same directory. Also same thing for src/finiteVolume/fvMesh/extendedStencil/faceToCell/fullStencils/CFCFaceToCellStencil.H.
After these changes (no changes to files in src/finiteVolume/fvMesh/extendedStencil/cellToFace/MeshObjects ), I didn't see the reported errors anymore.
(there were some unrelated errors while compiling activeBaffleVelocityFvPatchVectorField.C, directMappedFixedValueFvPatchFields.C, and directMappedVelocityFluxFixedValueFvPatchField.C. However, "wmake libso finteVolume" was successful after I commented the lines related to these three files in src/finiteVolume/Make/files)
However, there are still other errors (which I believe was not because of the changes I made) while compiling with gcc-4.1.2. For example, while doing "wmake libso dynamicMesh", I got the following error:
slidingInterface/enrichedPatch/enrichedPatchMasterPoints.C: In member function 'void Foam::enrichedPatch::calcMasterPointFaces() const':
slidingInterface/enrichedPatch/enrichedPatchMasterPoints.C:78: error: no matching function for call to 'Foam:: DynamicList<int, 0u, 2u, 1u>:: DynamicList(Foam:: DynamicList<int, 0u, 2u, 1u>)'
slidingInterface/enrichedPatch/enrichedPatchMasterPoints.C:117: error: no matching function for call to 'Foam:: DynamicList<int, 0u, 2u, 1u>:: DynamicList(Foam:: DynamicList<int, 0u, 2u, 1u>)'
While doing "wmake libso autoMesh", I got the following error:
autoHexMesh/meshRefinement/meshRefinement.C: In member function 'void Foam::meshRefinement::calcNeighbourData(Foam::labe lList&, Foam:: pointField&) const':
autoHexMesh/meshRefinement/meshRefinement.C:87: error: call of overloaded 'HashSet(Foam::labelList)' is ambiguous
~/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/HashSet.H:98: note: candidates are: Foam::HashSet<Key, Hash>::HashSet(const Foam::HashSet<Key, Hash>&) [with Key = int, Hash = Foam::Hash<int>]
~/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/HashSet.H:87: note: Foam::HashSet<Key, Hash>::HashSet(const Foam::UList<T>&) [with Key = int, Hash = Foam::Hash<int>]
Any help on this will be highly appreciated. Thanks.
This problem is a bug in older releases of gcc, please try with gcc-4.3.3 as supplied with OpenFOAM-1.6.
Thanks for the information. I understand that it's a problem with gcc, not OF itself. It would be nice if we have a workaround for this, since some users like me may not be able to install our own compilers (due to the special architecture of the system etc.).
Thanks again to you and other OF developers for this nice tool for CFD.
gcc need not be installed in the standard system location; you can install gcc-4.3.3 in OpenFOAM/ThirdParty-1.6 for example and set your environment variables appropriately as we did for the release of OpenFOAM-1.6. This way your use of gcc-4.3.3 for OpenFOAM does not interfere with the rest of the system or other applications you run.
|All times are GMT -4. The time now is 14:54.|