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)