The gnupg-2.2.19 fails to build on latest Fedora Rawhide with the distro-wide C/ld optimization flags which include LTO.
The problem is in duplicated (same) global data across multiple object files.
Description
Description
Details
Details
- Version
- 2.2.19
Revisions and Commits
Revisions and Commits
| rG GnuPG | |||
| rG6aff8a132815 build: Always use EXTERN_UNLESS_MAIN_MODULE pattern. | |||
| rG21d9bd8b87a9 build: Always use EXTERN_UNLESS_MAIN_MODULE pattern. | |||
Related Objects
Related Objects
- Mentioned In
- T4860: Release GnuPG 2.2.20
Event Timeline
Comment Actions
You mean that common blocks can't be used anymore? The RISC-OS had this problem but it was the only architecture I was aware of that required "extern" trickery.
Comment Actions
In a private mail someone else reported a similar problems and explained that gcc-10 will change the default from -fcommon to -fno-common. I think this is again a bad move in compiler development. Replacing the de-facto standard C compiler behaviour with something _allowed_ by ISO-C. No industrial grade toolchain would ever do such a silly default change - too many customers would rightfully be angry with them.
Quite some time ago I realized that supporting RISC-OS is nt anymore something we should do with GnUPG becuase we can't test it anyway. Thus I started to remove or didn't implemented RISC-OS specific hacks anymore. The common blocks thing is one of them.
We need to see what we can do; it is not just GnuPG but likely lot of libraries and other code we maintain.
In the concrete case an accessor function might be a better way than to add macros all over the place.
Comment Actions
I took your patch but modified it to define EXTERN_UNLESS_MAIN_MODULE only at one place.