gdcm build failure for Leap 15.4
Hi, gdcm is a graphics library for DICOM images. It builds fine for Leap 15.3 and TW, but fails for 15.4: From https://build.opensuse.org/build/home:DocB:Orthanc/15.4/x86_64/gdcm/_log Error: https://paste.opensuse.org/20682002 The issue seems to be related to libpoppler (22.01). Can one of the C++ experts explain why it fails just for Leap 15.4? Thanks Axel
On Tue, 08 Mar 2022 09:32:39 +0100 Axel Braun wrote:
gdcm is a graphics library for DICOM images. It builds fine for Leap 15.3 and TW, but fails for 15.4: From https://build.opensuse.org/build/home:DocB:Orthanc/15.4/x86_64/gdcm/_log Error: https://paste.opensuse.org/20682002
The issue seems to be related to libpoppler (22.01). Can one of the C++ experts explain why it fails just for Leap 15.4?
just some hints: /usr/include/poppler/Form.h:320:10: error: 'optional' in namespace 'std' does not name a template type std::optional<GooString> getCheckedSignature(Goffset *checkedFileSize); ^~~~~~~~ "std::optional" is defined in the C++ standard C++17. GCC-7 (of openSUSE Leap 15.4) up to GCC-10 use the standard C++14 by default. The used gcc7-7.5.0 should support "optional", but C++17 support has to be enabled explicitly with the option: -std=c++17 (or -std=gnu++17 if GNU extensions are wanted). https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 For GCC-11 the default standard is C++17, therefore the package builds in Tumbleweed. https://gcc.gnu.org/gcc-11/changes.html#cxx Kind regards, Dieter
(apologies for 'hijacking' the thread) On Tue, 08 Mar 2022 12:02:04 +0100 dieter wrote:
On Tue, 08 Mar 2022 09:32:39 +0100 Axel Braun wrote:
gdcm is a graphics library for DICOM images. It builds fine for Leap 15.3 and TW, but fails for 15.4: From https://build.opensuse.org/build/home:DocB:Orthanc/15.4/x86_64/gdcm/_log Error: https://paste.opensuse.org/20682002
The issue seems to be related to libpoppler (22.01). Can one of the C++ experts explain why it fails just for Leap 15.4?
just some hints: /usr/include/poppler/Form.h:320:10: error: 'optional' in namespace 'std' does not name a template type std::optional<GooString> getCheckedSignature(Goffset *checkedFileSize); ^~~~~~~~
Application:Geo/gdal build for 15.4 fails with identical error, while trying to build (optional) SpatialPDF driver, for which poppler is the dependency.
"std::optional" is defined in the C++ standard C++17. GCC-7 (of openSUSE Leap 15.4) up to GCC-10 use the standard C++14 by default.
AFAICT, poppler is built with gcc11 on 15.4, due to some other issue with gcc-7.5.0
The used gcc7-7.5.0 should support "optional", but C++17 support has to be enabled explicitly with the option: -std=c++17 (or -std=gnu++17 if GNU extensions are wanted).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017
So, what's the 'proper', least intrusive way to deal with this, apart from disabling SpatialPDF driver for 15.4? Explicitly set '-std=c++17' in gdal build? Use gcc-11(that would be overkill, I presume)? Any gotchas to be aware of with any of these? Pedja
On Tue, 8 Mar 2022, Predrag Ivanović wrote:
(apologies for 'hijacking' the thread)
On Tue, 08 Mar 2022 12:02:04 +0100 dieter wrote:
On Tue, 08 Mar 2022 09:32:39 +0100 Axel Braun wrote:
gdcm is a graphics library for DICOM images. It builds fine for Leap 15.3 and TW, but fails for 15.4: From https://build.opensuse.org/build/home:DocB:Orthanc/15.4/x86_64/gdcm/_log Error: https://paste.opensuse.org/20682002
The issue seems to be related to libpoppler (22.01). Can one of the C++ experts explain why it fails just for Leap 15.4?
just some hints: /usr/include/poppler/Form.h:320:10: error: 'optional' in namespace 'std' does not name a template type std::optional<GooString> getCheckedSignature(Goffset *checkedFileSize); ^~~~~~~~
Application:Geo/gdal build for 15.4 fails with identical error, while trying to build (optional) SpatialPDF driver, for which poppler is the dependency.
"std::optional" is defined in the C++ standard C++17. GCC-7 (of openSUSE Leap 15.4) up to GCC-10 use the standard C++14 by default.
AFAICT, poppler is built with gcc11 on 15.4, due to some other issue with gcc-7.5.0
The used gcc7-7.5.0 should support "optional", but C++17 support has to be enabled explicitly with the option: -std=c++17 (or -std=gnu++17 if GNU extensions are wanted).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017
So, what's the 'proper', least intrusive way to deal with this, apart from disabling SpatialPDF driver for 15.4? Explicitly set '-std=c++17' in gdal build? Use gcc-11(that would be overkill, I presume)? Any gotchas to be aware of with any of these?
Note that C++17 is still considered experimental with GCC 7 (but not with GCC 9+), so there can be ABI issues which means you should generally avoid linking C++17 code from GCC 11 with GCC 7 compiled code when using -std=c++17 there - GCC 7 compiled code when _not_ using -std=c++17 (so -std=c++14 and below) is fine though. That doesn't really explain why the _compile_ fails with 15.4 but not with 15.3. I suspect code changes in the gdcm dependences since GCC did not change (nor did gdcm as you say). Richard.
So, what's the 'proper', least intrusive way to deal with this, apart from disabling SpatialPDF driver for 15.4? Explicitly set '-std=c++17' in gdal build? Use gcc-11(that would be overkill, I presume)? Any gotchas to be aware of with any of these?
Note that C++17 is still considered experimental with GCC 7 (but not with GCC 9+), so there can be ABI issues which means you should generally avoid linking C++17 code from GCC 11 with GCC 7 compiled code when using -std=c++17 there - GCC 7 compiled code when _not_ using -std=c++17 (so -std=c++14 and below) is fine though.
That doesn't really explain why the _compile_ fails with 15.4 but not with 15.3. I suspect code changes in the gdcm dependences since GCC did not change (nor did gdcm as you say). The 15.3 build of gdcm according to the build log from the original poster uses libpoppler89-0.79.0-3.3.1, the 15.4 build uses
On Tue, 8 Mar 2022 16:13:08 +0100 (CET) Richard Biener wrote: libpoppler117-22.01.0-150400.1.1. Therefore I assume the C++17 dependency is only in newer libpoppler versions. If libpoppler in 15.4 is already built using GCC-11 I think there is no problem building other packages - like gdal or gdcm - which depend on it also with GCC-11. Kind regards, Dieter
Hello Dieter, Am Dienstag, 8. März 2022, 12:02:04 CET schrieb dieter: ....
The used gcc7-7.5.0 should support "optional", but C++17 support has to be enabled explicitly with the option: -std=c++17 (or -std=gnu++17 if GNU extensions are wanted).
adding the compiler option fixed the problem for Leap 15.4. Other builds are running to make sure it does not break the rest. Thanks for the hint! Axel
On Tue, 08 Mar 2022 17:23:12 +0100 Axel Braun wrote:
adding the compiler option fixed the problem for Leap 15.4. Other builds are running to make sure it does not break the rest.
Thanks for the hint!
Thanks for the confirmation that this was indeed the problem. With the additional information from Pedja that libpoppler for Leap 15.4 is already being built using GCC-11 and from Richard better not to mix C++17 binaries generated by GCC-7 and GCC-11 the better solution is to build also gdcm for Leap 15.4 using GCC-11. Kind regards, Dieter
Hello Dieter, Am Dienstag, 8. März 2022, 17:44:13 CET schrieb dieter:
adding the compiler option fixed the problem for Leap 15.4. Other builds are running to make sure it does not break the rest.
Thanks for the hint!
Thanks for the confirmation that this was indeed the problem.
With the additional information from Pedja that libpoppler for Leap 15.4 is already being built using GCC-11 and from Richard better not to mix C++17 binaries generated by GCC-7 and GCC-11 the better solution is to build also gdcm for Leap 15.4 using GCC-11.
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? (Not to mention the exta spins one needs to take with regard to the python 3.6 stack. Different area, similar issue) Cheers Axel
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? The problem with mixing code generated by different compiler versions arises if a specific ABI changes between these two versions. In this case - according to Richards mail - when using gcc-7 with the switch "-std=c++17" the generated code should not be mixed with gcc-11 generated code for C++17. So if the libpoppler version in Leap 15.4 using C++17 features is already built with GCC-11 and exports interfaces requiring its users also to be built with C++17 support then these users ideally should also be built using GCC-11. Whereas dependencies further down the line which do not require to be built with C++17 support can be built using GCC-7, e.g. if libgdcm fully encapsulates the interface to
Hi Axel, On Tue, 08 Mar 2022 20:18:38 +0100 Axel Braun wrote: libpoppler and users of libgdcm do not need C++17 support they can be built using GCC-7. I am afraid I can not tell how risky the mixing is and how obvious problems would be. Kind regards, Dieter
On Wed, 9 Mar 2022, dieter wrote:
Hi Axel,
On Tue, 08 Mar 2022 20:18:38 +0100 Axel Braun wrote:
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? The problem with mixing code generated by different compiler versions arises if a specific ABI changes between these two versions. In this case - according to Richards mail - when using gcc-7 with the switch "-std=c++17" the generated code should not be mixed with gcc-11 generated code for C++17. So if the libpoppler version in Leap 15.4 using C++17 features is already built with GCC-11 and exports interfaces requiring its users also to be built with C++17 support then these users ideally should also be built using GCC-11. Whereas dependencies further down the line which do not require to be built with C++17 support can be built using GCC-7, e.g. if libgdcm fully encapsulates the interface to libpoppler and users of libgdcm do not need C++17 support they can be built using GCC-7. I am afraid I can not tell how risky the mixing is and how obvious problems would be.
One cannot make guesses here, the issues could be very obvious or well hidden (just some silent data corruption for example). If as in this case an application is built with gcc7 and C++17 and linking against a library built with gcc11 and C++17 the issue is that the experimental ABI libstdc++ C++17 STL parts instantiated in the application will provide the implementation for the library (in case it uses the same libstdc++ C++17 STL facility and that has a different stable ABI) according to the ELF symbol resolution rules unless the library was build in very specific ways binding locally to those symbols which unfortunately C++ libraries tend not to (because it's quite difficult to constrain what to export and what not there). I'm not sure if it would be easily possible to mitigate that issue on the application side - of course when the API between the application and the library uses C++17 features with differing API/ABI that doesn't help, but those cases tend to cause more obvious issues. Unfortunately it is not documented which ABI changes happened between gcc7 and gcc9 (when the ABI was finalized for C++17). Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
On Fri, 11 Mar 2022 09:48:52 +0100 (CET) Richard Biener wrote:
One cannot make guesses here, the issues could be very obvious or well hidden (just some silent data corruption for example). ...
I also think so. In the last decade C++ standards have become fast moving targets in relation to enterprise distribution timelines. Much less then python though. In theory system libraries should be built with the system compiler. But users (or SLE customers) who use gcc-11 - which is also part of the distribution - to develop their own software would also face these possible ABI issues. Therefore maybe there should be a general guideline to build distribution packages which require C++17 features with gcc-11 and not with gcc-7 + "-std=c++17". In order to avoid unstable ABI parts to be included which could result in undefined behavior, crashes or security problems. And also a hint for users/customers who build their own C++ projects to use gcc-11 if they need C++17 support. What anyway makes sense also because of other improvements. Kind regards, Dieter
On Fri, 11 Mar 2022, dieter wrote:
On Fri, 11 Mar 2022 09:48:52 +0100 (CET) Richard Biener wrote:
One cannot make guesses here, the issues could be very obvious or well hidden (just some silent data corruption for example). ...
I also think so. In the last decade C++ standards have become fast moving targets in relation to enterprise distribution timelines. Much less then python though. In theory system libraries should be built with the system compiler. But users (or SLE customers) who use gcc-11 - which is also part of the distribution - to develop their own software would also face these possible ABI issues.
Therefore maybe there should be a general guideline to build distribution packages which require C++17 features with gcc-11 and not with gcc-7 + "-std=c++17". In order to avoid unstable ABI parts to be included which could result in undefined behavior, crashes or security problems. And also a hint for users/customers who build their own C++ projects to use gcc-11 if they need C++17 support. What anyway makes sense also because of other improvements.
Fact is the system compiler only supports C++17 experimentally, so it's actually unsupported. That means system software components should refrain themselves from using C++17, it's too new and shiny. What C++17 feature does poppler (it was poppler?) use? GCC 7 supports C++14 just fine. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
On Freitag, 11. März 2022 14:57:49 CET Richard Biener wrote:
What C++17 feature does poppler (it was poppler?) use? GCC 7 supports C++14 just fine.
(at least) std::optional Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Fri, 11 Mar 2022, Stefan Brüns wrote:
On Freitag, 11. März 2022 14:57:49 CET Richard Biener wrote:
What C++17 feature does poppler (it was poppler?) use? GCC 7 supports C++14 just fine.
(at least) std::optional
(at least) std::variant and std::filesystem::path changed ABI. Note an issue will trigger only if both the application and the library use a problematical interface. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
On Tue, 8 Mar 2022, Axel Braun wrote:
Hello Dieter,
Am Dienstag, 8. März 2022, 17:44:13 CET schrieb dieter:
adding the compiler option fixed the problem for Leap 15.4. Other builds are running to make sure it does not break the rest.
Thanks for the hint!
Thanks for the confirmation that this was indeed the problem.
With the additional information from Pedja that libpoppler for Leap 15.4 is already being built using GCC-11 and from Richard better not to mix C++17 binaries generated by GCC-7 and GCC-11 the better solution is to build also gdcm for Leap 15.4 using GCC-11.
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? (Not to mention the exta spins one needs to take with regard to the python 3.6 stack. Different area, similar issue)
Mixing compiler-versions is OK as long as you are not ending up with experimental ABIs. I was pointing out that GCC-7 still has an experimental C++17 ABI (on the library side), that can, but needs not to, result in issues. So yes, I would also suggest to build gdcm with GCC-11 (but I'd also argue that building poppler with the non-system compiler was a bad idea). Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
Hello richard, Am Mittwoch, 9. März 2022, 13:38:36 CET schrieb Richard Biener: ...
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? (Not to mention the exta spins one needs to take with regard to the python 3.6 stack. Different area, similar issue)
Mixing compiler-versions is OK as long as you are not ending up with experimental ABIs. I was pointing out that GCC-7 still has an experimental C++17 ABI (on the library side), that can, but needs not to, result in issues. So yes, I would also suggest to build gdcm with GCC-11 (but I'd also argue that building poppler with the non-system compiler was a bad idea).
So, proposal is to follow the path which you do not in general propose, just because one made a wrong turn. I tested a bit using the gcc11-c++ compiler, which alone does not give a working compilation (bunch of error messages). i gave up at some point For now https://build.opensuse.org/request/show/960283 is waiting for approval (ideally after review from a graphics maintainer) Cheers Axel
On Thu, 10 Mar 2022, Axel Braun wrote:
Hello richard,
Am Mittwoch, 9. März 2022, 13:38:36 CET schrieb Richard Biener:
...
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? (Not to mention the exta spins one needs to take with regard to the python 3.6 stack. Different area, similar issue)
Mixing compiler-versions is OK as long as you are not ending up with experimental ABIs. I was pointing out that GCC-7 still has an experimental C++17 ABI (on the library side), that can, but needs not to, result in issues. So yes, I would also suggest to build gdcm with GCC-11 (but I'd also argue that building poppler with the non-system compiler was a bad idea).
So, proposal is to follow the path which you do not in general propose, just because one made a wrong turn.
I tested a bit using the gcc11-c++ compiler, which alone does not give a working compilation (bunch of error messages). i gave up at some point
For now https://build.opensuse.org/request/show/960283 is waiting for approval (ideally after review from a graphics maintainer)
The BuildRequires: gcc-c++ >= 11 is going to fail on Leap, you'd have to use BuildRequires: gcc11-c++ and in %build do CXX=g++-11 and hope that cmake picks that up ... Richard.
Am Freitag, 11. März 2022, 09:37:01 CET schrieb Richard Biener:
On Thu, 10 Mar 2022, Axel Braun wrote:
Hello richard,
Am Mittwoch, 9. März 2022, 13:38:36 CET schrieb Richard Biener:
...
So you are proposing to set a BuildRequirement to gcc11-c++ ? unfortunately its not just that easy. And in general - should mixing compiler versions not be forbidden if this creates issues? (Not to mention the exta spins one needs to take with regard to the python 3.6 stack. Different area, similar issue)
Mixing compiler-versions is OK as long as you are not ending up with experimental ABIs. I was pointing out that GCC-7 still has an experimental C++17 ABI (on the library side), that can, but needs not to, result in issues. So yes, I would also suggest to build gdcm with GCC-11 (but I'd also argue that building poppler with the non-system compiler was a bad idea).
So, proposal is to follow the path which you do not in general propose, just because one made a wrong turn.
I tested a bit using the gcc11-c++ compiler, which alone does not give a working compilation (bunch of error messages). i gave up at some point
For now https://build.opensuse.org/request/show/960283 is waiting for approval (ideally after review from a graphics maintainer)
The
BuildRequires: gcc-c++ >= 11
is going to fail on Leap, you'd have to use
BuildRequires: gcc11-c++
and in %build do
CXX=g++-11
and hope that cmake picks that up ...
Thank you for the hint. With some conditions in the spec file it now builds for Leap, and fails for TW. I guess this is due a recent poppler-update (again): https://paste.opensuse.org/96354932 My guess is that is for upstream to fix Cheers Axel
participants (5)
-
Axel Braun -
dieter -
Predrag Ivanović -
Richard Biener -
Stefan Brüns