View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001474 | OpenFOAM | Bug | public | 2015-01-03 20:39 | 2016-10-04 08:35 |
| Reporter | wyldckat | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | dev | ||||
| Summary | 0001474: Feedback on the 64-bit labels recently implemented | ||||
| Description | Not sure if this is going to be the only issue, but so far the first one I found, at least with GCC 4.6.3, is that this was missing: -D__STDC_LIMIT_MACROS in the build options. Without it, tons of the following happen during building: /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:61:1: error: ‘INT64_MIN’ was not declared in this scope /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:62:1: error: ‘INT64_MAX’ was not declared in this scope similar happens with the 32-bit labels. | ||||
| Additional Information | Quick fix/patch: diff --git a/wmake/rules/linux64Gcc/c++ b/wmake/rules/linux64Gcc/c++ index a23dd82..2e88664 100644 --- a/wmake/rules/linux64Gcc/c++ +++ b/wmake/rules/linux64Gcc/c++ @@ -9,7 +9,7 @@ CC = g++ -m64 include $(RULES)/c++$(WM_COMPILE_OPTION) -ptFLAGS = -DNoRepository -ftemplate-depth-100 +ptFLAGS = -DNoRepository -ftemplate-depth-100 -D__STDC_LIMIT_MACROS c++FLAGS = $(GFLAGS) $(c++WARN) $(c++OPT) $(c++DBUG) $(ptFLAGS) $(LIB_HEADER_DIRS) -fPIC | ||||
| Tags | No tags attached. | ||||
|
|
Maintaning backward compatibility with old gcc versions is becoming increasingly problematic and at the moment I only test back to gcc-4.7.2 for releases. I have tested the latest OpenFOAM-dev with gcc-4.8.1, 4.9.2 and Clang-3.5.0. I will add the -D__STDC_LIMIT_MACROS to the gcc rules for 4.5 and 4.6 and with check if it is needed for 4.7. |
|
|
I am building with gcc-4.7.2 and -D__STDC_LIMIT_MACROS is not needed |
|
|
I am now building with gcc-4.6.4 and -D__STDC_LIMIT_MACROS is not needed |
|
|
Is this an issue with the gcc version or your system header files? |
|
|
I haven't managed yet to test on more systems other than on my main machine, which is using Ubuntu 12.04 x86_64. The header it's using is the default one at "/usr/include/stdint.h". Tomorrow (er, today) I'll test on a few more virtual machines with other Linux Distributions/versions, to assess what's going on. I do have a tendency to manage some crazy building conditions sometimes... even if I'm mostly using standard installations with standard options... |
|
|
OK, I've isolated the source of this issue. This was a fix that was implemented in libc: - Bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15366 - The commit that fixed this: https://sourceware.org/git/?p=glibc.git;a=commit;h=1ef74943ce2f114c78b215af57c2ccc72ccdb0b7 - Was made part of libc as of version 2.18: https://sourceware.org/git/?p=glibc.git;a=tag;h=f470138ba1124af9cffb839912538bbab2d0ca07 Therefore, if the libc library in use is 2.18 or newer (10 Aug 2013), then this definition "__STDC_LIMIT_MACROS" is not necessary. OK, this is certainly annoying... CentOS/RHEL 7.0 is using libc 2.17, which doesn't have this fix yet. I'll test if "std::numeric_limits<int32_t>::max()" is more generic than "INT32_MAX". Source for this idea: http://stackoverflow.com/questions/3233054/error-int32-max-was-not-declared-in-this-scope |
|
|
> I'll test if "std::numeric_limits<int32_t>::max()" is more generic than "INT32_MAX". This requires C++11 support which we don't yet rely on in order to maintain support for gcc-4.5 and gcc-4.6. Initially I used cstdint rather than stdint.h but this would have limited gcc versions to 4.7 or higher and required the use of the C++11 support option. At some point I would like to use much of the C++11 functionality in OpenFOAM but we have to wait until support for Ubuntu 12.04 and other old GNU/Linux releases is no longer needed. I have successfully completed testing of OpenFOAM-dev with gcc-4.[5-8].4, gcc-4.9.2 and clang-3.5.0: no problems. |
|
|
> I have successfully completed testing of OpenFOAM-dev with gcc-4.[5-8].4, gcc-4.9.2 and clang-3.5.0: no problems. My guess is that you did not have any problems because your system has got "libc" 2.18, 2.19 or newer. You might not have as much success with a system with "libc" 2.17 or older. While testing with "numeric_limits", I spotted a few stray "INT_MAX" (and UINT_MAX) macros that can be harmful sometime in the future. Perhaps it's best to either switch them to "INT32_MAX" or something more explicitly generic. You can find them by running: find src -name *.[CH] -type f | xargs grep INT_MAX In the mean time I'll continue testing with "numeric_limits". As far as I can figure out, there was a fix made on "numeric_limits::min/max" in C++11 to have it return as "constexpr" or something like that. But otherwise, this is something that has existed for far longer than C++11. I'll test "numeric_limits::min/max" on my current system, on a much older and on a much newer system, to assess if using "numeric_limits" is bullet-proof or not to "libc" versions and C++ standards. |
|
|
I will check the use of INT_MAX as you suggest. If "numeric_limits::min/max" proves problematic on old systems as an interim solution I am OK adding #define __STDC_LIMIT_MACROS just before the inclusion of stdint.h as suggested in the bug-reports you dug-up. |
|
|
Now I understand it better... this is why you had stated that "numeric_limits::min/max" was C++11 only: static const label labelMin = INT_SIZE(INT, _MIN); static const label labelMax = INT_SIZE(INT, _MAX); precisely due to the new feature "constexpr" in C++11. ----------------- edit: Mainly because of this: syncTools::syncEdgeList ( mesh_, edgeLevel, ifEqEqOp<labelMax>(), labelMin ); ---------------- Then I'll test with: #define __STDC_LIMIT_MACROS before all "#include <stdint.h>" in OpenFOAM's own source code. |
|
|
> find src -name *.[CH] -type f | xargs grep INT_MAX Most of these occurrences relate specifically to type int and hence using INT_MAX is correct. The only exceptions are in ptscotchDecomp.C and scotchDecomp.C which should now use labelMax. I will push this change. |
|
|
I am testing using numeric_limits at the moment and so far I have not had any problems. I will test build with gcc-4.[5-9] and clang-3.5.0 before pushing the change. |
|
|
I have hit the same problem you hit, back to #define __STDC_LIMIT_MACROS |
|
|
Resolved by commit 097f23e11a3ee5c4e93ffc68b89614265459e6d5 by inserting #define __STDC_LIMIT_MACROS before #include <stdint.h> When we stop supporting old GNU/Linux versions and upgrade to C++11 this nonsense will be replaced with cstdint and numeric_limits. |
|
|
Sorry, gotta reopen this report with some more information. This happened both with the hacks I had tried before your commit, as well with a fresh "git pull": In file included from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/doubleFloat.H:29:0, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/floatScalar.H:38, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/scalar.H:39, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/VectorSpace.H:43, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Vector.H:44, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Tensor.H:41, from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/tensor.H:38, from lnInclude/indexedVertex.H:42, from conformalVoronoiMesh/CGALTriangulation3Ddefs.H:43, from conformalVoronoiMesh/conformalVoronoiMesh.H:44, from conformalVoronoiMesh/conformalVoronoiMeshFeaturePoints.C:26: /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:61:1: error: ‘INT32_MIN’ was not declared in this scope /home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/label.H:62:1: error: ‘INT32_MAX’ was not declared in this scope Attached is a patch file "foamyIncludeOrder.patch" with the changes that seemed to fix this issue. I haven't taken the time to further debug this, but something in the "CGALTriangulation3Ddefs.H" and "CGALTriangulation2Ddefs.H" is interfering with the "#define __STDC_LIMIT_MACROS". I think I deduced it now... CGAL's headers also include the "stdint.h" before OpenFOAM's own headers. |
|
|
foamyIncludeOrder.patch (2,559 bytes)
diff --git a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H index eb1cf68..b85fb37 100644 --- a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H +++ b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/conformalVoronoiMesh.H @@ -41,8 +41,8 @@ SourceFiles #ifndef conformalVoronoiMesh_H #define conformalVoronoiMesh_H -#include "CGALTriangulation3Ddefs.H" #include "uint.H" +#include "CGALTriangulation3Ddefs.H" #include "searchableSurfaces.H" #include "conformationSurfaces.H" #include "cellShapeControl.H" diff --git a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H index e3c415b..e832b29 100644 --- a/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H +++ b/applications/utilities/mesh/generation/foamyHexMesh/conformalVoronoiMesh/conformalVoronoiMesh/featurePointConformer/featurePointConformer.H @@ -39,12 +39,12 @@ SourceFiles #ifndef featurePointConformer_H #define featurePointConformer_H -#include "CGALTriangulation3Ddefs.H" #include "vector.H" #include "DynamicList.H" #include "List.H" #include "extendedFeatureEdgeMesh.H" #include "pointPairs.H" +#include "CGALTriangulation3Ddefs.H" // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // diff --git a/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H b/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H index 4948196..e3e316a 100644 --- a/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H +++ b/applications/utilities/mesh/generation/foamyQuadMesh/CV2D.H @@ -117,8 +117,6 @@ SourceFiles #define CGAL_INEXACT #define CGAL_HIERARCHY -#include "CGALTriangulation2Ddefs.H" - #include "Time.H" #include "point2DFieldFwd.H" #include "dictionary.H" @@ -134,6 +132,8 @@ SourceFiles #include "relaxationModel.H" #include "cellSizeAndAlignmentControls.H" +#include "CGALTriangulation2Ddefs.H" + // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // namespace Foam |
|
|
I applied the patch but re-ordered a bit and added a comment. Maybe it would be more obvious if we simply define __STDC_LIMIT_MACROS before the CGAL headers are included. Please re-open if there are any remaining issues with this. |
|
|
There is a problem with - compiling Pstream - with IntelMPI - with g++ (clang++ is ok) What seems to be happening: - Intel mpi.h pulls in /usr/include/stdint.h but without setting __STDC_LIMIT_MACROS - so then when it comes to uint32.H it does not include stdin.h anymore. Solution: add #define __STDC_LIMIT_MACROS to src/Pstream/mpi/UIPread.C src/Pstream/mpi/UPstream.C src/Pstream/mpi/UOPwrite.C src/Pstream/mpi/PstreamGlobals.C before #include "mpi.h" |
|
|
I want to avoid the proliferation of __STDC_LIMIT_MACROS which is a temporary work-around for old C++ compilers. Why not move the include of mpi.h after the OpenFOAM headers? |
|
|
Sounds good. Is what we're doing already in e.g. ptscotchDecomp.C and zoltanRenumber.C |
|
|
#define __STDC_LIMIT_MACROS removed from OpenFOAM-dev: commit dee026476892e0870b59fbc0cbe8de2fa46d0508 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-03 20:39 | wyldckat | New Issue | |
| 2015-01-03 21:14 | henry | Note Added: 0003484 | |
| 2015-01-03 21:23 | henry | Note Added: 0003485 | |
| 2015-01-03 23:34 | henry | Note Added: 0003493 | |
| 2015-01-03 23:35 | henry | Note Added: 0003494 | |
| 2015-01-04 01:25 | wyldckat | Note Added: 0003495 | |
| 2015-01-04 11:13 | wyldckat | Note Added: 0003496 | |
| 2015-01-04 12:06 | henry | Note Added: 0003497 | |
| 2015-01-04 13:31 | wyldckat | Note Added: 0003498 | |
| 2015-01-04 13:46 | henry | Note Added: 0003499 | |
| 2015-01-04 15:20 | wyldckat | Note Added: 0003501 | |
| 2015-01-04 15:21 | wyldckat | Note Edited: 0003501 | |
| 2015-01-04 15:45 | henry | Note Added: 0003503 | |
| 2015-01-04 18:22 | henry | Note Added: 0003504 | |
| 2015-01-04 18:51 | henry | Note Added: 0003505 | |
| 2015-01-04 20:18 | henry | Note Added: 0003506 | |
| 2015-01-04 20:18 | henry | Status | new => resolved |
| 2015-01-04 20:18 | henry | Resolution | open => fixed |
| 2015-01-04 20:18 | henry | Assigned To | => henry |
| 2015-01-04 22:05 | wyldckat | Note Added: 0003507 | |
| 2015-01-04 22:05 | wyldckat | Status | resolved => feedback |
| 2015-01-04 22:05 | wyldckat | Resolution | fixed => reopened |
| 2015-01-04 22:06 | wyldckat | File Added: foamyIncludeOrder.patch | |
| 2015-01-04 23:46 | henry | Note Added: 0003508 | |
| 2015-01-04 23:46 | henry | Status | feedback => resolved |
| 2015-01-04 23:46 | henry | Resolution | reopened => fixed |
| 2015-06-26 12:03 |
|
Note Added: 0005004 | |
| 2015-06-26 12:11 | henry | Note Added: 0005005 | |
| 2015-06-26 12:37 |
|
Note Added: 0005006 | |
| 2016-10-04 08:35 | henry | Note Added: 0006956 |
