Undefine "extended" macro temporarily on GNU Hurd #5047
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GNU Mach microkernel header files (gnumach-dev 1.8+git20201129) added to
struct i386_xfp_save
in /usr/include/i386-gnu/include/mach/i386/fp_reg.ha new
extended
field which happens to collide with the macro definition#define extended double
in FontForge, leading to FTBFS on GNU Hurd:This issue may be circumvented by temporarily undefining the
extended
macro before loading<gio/gio.h>
and friends, and redefining theextended
macro right after, as is done in this PR.For Debian packaging, in fontforge (1:20201107~dfsg-4) released 2021-01-15, I replaced all relevant instances of
extended
withextendeddbl
to avoid macro/type name collision; see my patch at https://sources.debian.org/src/fontforge/1%3A20201107~dfsg-4/debian/patches/0005-hurd-rename-extended-to-avoid-conflict-with-gnumach-dev.patch/However, when it came time to upgrade to fontforge (1:20220308~dfsg-1) on 2022-06-16, I realized such a patch would be very hard to maintain in the long run. Fortunately, I came across instances of
#undef extended
in the existing codebase for avoiding conflict with xlink.h, and borrowed the idea for this pull request. I am happy to report that this allows fontforge to build successfully on hurd-i386; see https://buildd.debian.org/status/logs.php?pkg=fontforge&ver=1%3A20220308%7Edfsg-1&arch=hurd-i386Type of change