-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation with GCC 8.2.0 fails #3798
Comments
Do you have a way of testing GCC 9.x or later? This may be a compiler error or missing feature in GCC 8.x and/or a problem in the libstdc++ standard library implementation. The diagnostic message means that the compiler is unable to specialise If you don't have an easy way of testing GCC 9.x, I'd like to run a little experiment if you wouldn't mind. Can you create the following three files ( g++ -std=c++17 -Wall -Wextra -pedantic -o t main.cpp k.cpp && ./t If all goes well the command should print
to the shell. If not, do you get anything else if you replace k.hpp#include <memory>
#include <string>
class K
{
public:
K();
~K();
std::string str() const;
private:
class Impl;
std::unique_ptr<Impl> pImpl_;
}; k.cpp#include "k.hpp"
class K::Impl
{
public:
std::string str() const { return "pImpl"; }
};
K::K() : pImpl_ { std::make_unique<Impl>() } {}
K::~K() = default;
std::string K::str() const { return this->pImpl_->str(); } main.cpp#include "k.hpp"
#include <iostream>
int main()
{
K k{};
std::cout << "hello, " << k.str() << '\n';
} |
That example compiles with g++-8 (g++-8 -std=c++17 -c k.cpp -o k.o; g++-8 -std=c++17 -o main main.cpp k.o) with diff --git a/k.hpp b/k.hpp
index 396e94a..7c3a416 100644
--- a/k.hpp
+++ b/k.hpp
@@ -1,4 +1,5 @@
#include <string>
+#include <memory>
class K
{ |
Well, at least with g++-8.3.0-6 on Debian, which might have additional patches applied. |
Hm, weird. Did you have to |
@bska Thank you for the fast and helpful reply and for providing the code example. Next to GCC 8.2.0, I can also use GCC 9.3.0 or 11.4.0 (for those I just need to build a few missing dependencies like zoltan, but this should not take a lot of time). The example seems to build fine with all 3 compilers: GCC 8.2.0:
GCC 9.3.0:
GCC 11.4.0:
What also confuses me a bit is, that when the compilation fails and I rerun the command that failed: /cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DFMT_HEADER_ONLY -DHAVE_CONFIG_H=1 -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/cjson -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build/include -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final -isystem /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/fmtlib/include -isystem /cluster/apps/gcc-8.2.0/boost-1.74.0-bwdibdtazuvem2m7bwkiifvh7b3xvd5y/include -pipe -Wall -Wextra -Wshadow -fopenmp -pthread -O3 -DNDEBUG -ftree-vectorize -march=core-avx2 -mavx2 -UNDEBUG -fPIC -fopenmp -std=c++17 -MD -MT MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -MF MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o.d -o CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -c /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/Network/Node.cpp then this particular file Node.cpp compiles without error. Could the issue be related to CMake? Best regards Sam |
Right. To be honest, I think cmake --build . -target all --parallel 1 from the top-level build directory. This will definitely take longer and it's not something we do regularly, but when debugging build problems it's often a good thing to try first. I'd very much like to know what diagnostics you get from GCC 8.2 in this instance. |
@bska Thank you for your reply. I tried running the command that you provided for serial compilation. Now the compilation fails at 50%
Please find in the attachment the complete build logs (testmake.log). Thank you for helping me with this issue. |
Have you been able to somehow resolve this? |
No, I have not been able to resolve the issue |
Mmh. But you seem to have other compilers available. Do you need to to stick to 8.* because of other dependencies? |
Hi,
I am trying to build OPM-common (2023.10) on our HPC cluster. I use the following dependencies (all built from source code):
I follow the installation instructions and created the build directory, was running
ccmake ..
to change some variables (to disable the addition of-march=native
, as we have different node types in the cluster). Then I was runningmake -j 8
to build the software in parallel. At 40% the compilation failed with the following error:I started searching the internet for this error message and found:
https://stackoverflow.com/questions/20934195/invalid-application-of-sizeof-to-incomplete-type-created-classes
which seems to discuss a similar error. Is this a known problem? And do you have any idea on how to resolve this error?
Any help is appreciated.
Best regards
Sam
The text was updated successfully, but these errors were encountered: