Hello,
Not strictly a fedora devel question but I’m hoping all the experience and knowledge will be able to help. I need a newer poppler in epel 7. I’ve managed to bring it up to 0.68. However moving past that results in a compilation error. It seems the compiler (?) needs to support the c++14 standard. I’m using devtoolset-8 to get gcc 8.3.1 and from what I can find via google, this really should support c++14 (in this case std::string_literals). However when it compiles it sets the std to c++1y which was an alias for the draft of c++14 from what I can gather. If I go into a mock shell however and manually run it with --std=c++14 it still fails. When I grep through the includes for each it seems both have definitions for them but it still fails. Can anyone supplement what I have wrong here? Should c++ 8.3.1 be able to handle std::string_literals? It somewhat confuses me that people are talking about the compiler and not some library supporting it. Any pointers/help would be appreciated. Here’s a snippet of the build log.
/usr/bin/c++ -Dpoppler_EXPORTS -I/builddir/build/BUILD/poppler-0.73.0 -I/builddir/build/BUILD/poppler-0.73.0/fofi -I/builddir/build/BUILD/poppler-0.73.0/goo -I/builddir/build/BUILD/poppler-0.73.0/poppler -I/builddir/build/BUILD/poppler-0.73.0/build -I/builddir/build/BUILD/poppler-0.73.0/build/poppler -I/usr/include/freetype2 -I/usr/include/openjpeg-2.3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op -Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual -Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -g -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DQT_NO_DEBUG -fPIC -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -std=c++1y -o CMakeFiles/poppler.dir/fofi/FoFiType1.cc.o -c /builddir/build/BUILD/poppler-0.73.0/fofi/FoFiType1.cc /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:22: error: 'string_literals' is not a namespace-name using namespace std::string_literals; ^ /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:37: error: expected namespace-name before ';' token using namespace std::string_literals; ^ /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc: In function 'FILE* openFile(const char*, const char*)': /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:369:38: error: unable to find string literal operator 'operator"" s' const std::string modeStr = mode + "e”s;
Thanks in advance for anyone able to shed some light on this for me.
Sincerely, — Nathanael
On 14/12/2019 18:00, Nathanael Noblet wrote:
Not strictly a fedora devel question but I’m hoping all the experience and knowledge will be able to help. I need a newer poppler in epel 7. I’ve managed to bring it up to 0.68. However moving past that results in a compilation error. It seems the compiler (?) needs to support the c++14 standard. I’m using devtoolset-8 to get gcc 8.3.1 and from what I can find via google, this really should support c++14 (in this case std::string_literals). However when it compiles it sets the std to c++1y which was an alias for the draft of c++14 from what I can gather. If I go into a mock shell however and manually run it with --std=c++14 it still fails. When I grep through the includes for each it seems both have definitions for them but it still fails. Can anyone supplement what I have wrong here? Should c++ 8.3.1 be able to handle std::string_literals? It somewhat confuses me that people are talking about the compiler and not some library supporting it. Any pointers/help would be appreciated. Here’s a snippet of the build log.
Are you sure that the below /usr/bin/c++ really points to the devtoolset-8 GCC? GCC 8 (or rather, its accompanying libstdc++) should be new enough to support string_literals (see "User-defined literals for <chrono> and <string>" at https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B14_library_features).
/usr/bin/c++ -Dpoppler_EXPORTS -I/builddir/build/BUILD/poppler-0.73.0 -I/builddir/build/BUILD/poppler-0.73.0/fofi -I/builddir/build/BUILD/poppler-0.73.0/goo -I/builddir/build/BUILD/poppler-0.73.0/poppler -I/builddir/build/BUILD/poppler-0.73.0/build -I/builddir/build/BUILD/poppler-0.73.0/build/poppler -I/usr/include/freetype2 -I/usr/include/openjpeg-2.3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op -Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual -Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -g -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DQT_NO_DEBUG -fPIC -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -std=c++1y -o CMakeFiles/poppler.dir/fofi/FoFiType1.cc.o -c /builddir/build/BUILD/poppler-0.73.0/fofi/FoFiType1.cc /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:22: error: 'string_literals' is not a namespace-name using namespace std::string_literals; ^ /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:70:37: error: expected namespace-name before ';' token using namespace std::string_literals; ^ /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc: In function 'FILE* openFile(const char*, const char*)': /builddir/build/BUILD/poppler-0.73.0/goo/gfile.cc:369:38: error: unable to find string literal operator 'operator"" s' const std::string modeStr = mode + "e”s;
On Dec 14, 2019, at 10:46 AM, Stephan Bergmann sbergman@redhat.com wrote:
On 14/12/2019 18:00, Nathanael Noblet wrote:
Not strictly a fedora devel question but I’m hoping all the experience and knowledge will be able to help. I need a newer poppler in epel 7. I’ve managed to bring it up to 0.68. However moving past that results in a compilation error. It seems the compiler (?) needs to support the c++14 standard. I’m using devtoolset-8 to get gcc 8.3.1 and from what I can find via google, this really should support c++14 (in this case std::string_literals). However when it compiles it sets the std to c++1y which was an alias for the draft of c++14 from what I can gather. If I go into a mock shell however and manually run it with --std=c++14 it still fails. When I grep through the includes for each it seems both have definitions for them but it still fails. Can anyone supplement what I have wrong here? Should c++ 8.3.1 be able to handle std::string_literals? It somewhat confuses me that people are talking about the compiler and not some library supporting it. Any pointers/help would be appreciated. Here’s a snippet of the build log.
Are you sure that the below /usr/bin/c++ really points to the devtoolset-8 GCC? GCC 8 (or rather, its accompanying libstdc++) should be new enough to support string_literals (see "User-defined literals for <chrono> and <string>" at https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B14_library_features).
You are correct that I had the BuildRequires for devtoolset-8 but in double checking realized that I hadn’t enabled it prior to building!!! I was confused because when I went into the shell and enabled it and manually changed the command below it still failed so was confused by that. Now that I’ve added the proper call in the build section it is building. It still fails but not because of that anymore so I can move on to my next steps. Thanks for your help!
-
Nathanael Noblet -
Stephan Bergmann