Repository navigation
compat.fribidi on macOS and Windows; compat.xdmcp without arc4random_buf - #571
Merged
Merged
Conversation
compat.fribidi declared a Linux build only, so every macOS and Windows build that reaches it (openmui's text engine, pango) stopped at install. fribidi is portable C99 whose tables ship in the tarball and whose two config headers are written out here, so the same tarball serves all three platforms. The generated config.h no longer claims <strings.h> and <memory.h>: lib/common.h would include <strings.h>, which MSVC's headers do not have, and nothing in lib/ uses a function from either. compat.xdmcp declared HAVE_ARC4RANDOM_BUF, which assumes glibc 2.36+; on an older sysroot (the aarch64 one) Key.c's call is an implicit declaration, an error under C11. It now declares getentropy (glibc 2.25+) and lets Key.c's own arc4random_buf emulation use it.
The x86_64 sysroot's glibc (2.36+) declares arc4random_buf, so Key.c's own static definition conflicts with it; the aarch64 sysroot's older glibc does not, so a fixed HAVE_ARC4RANDOM_BUF is an implicit declaration there. A generated config.h reads the libc's version macros and chooses: the libc's arc4random_buf, or Key.c's emulation over getentropy (glibc 2.25+, musl).
Member
Author
|
Updated: the first version replaced HAVE_ARC4RANDOM_BUF with HAVE_GETENTROPY unconditionally, which made Key.c's static arc4random_buf conflict with glibc 2.36+'s declaration on the x86_64 sysroot (the graphics-install check). The choice now comes from the libc being compiled against, in a generated config.h: glibc ≥ 2.36 uses the libc's arc4random_buf; older glibc and musl use Key.c's getentropy emulation. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Two package definitions stop cross-platform builds of packages that reach them (found by openmui's CI, Sunrisepeak/mui#1):
has no build for macosx / windows). fribidi is portable C99: its Unicode tables ship in the tarball and its two config headers are written out in the descriptor, so the same tarball and checksum now servemacosxandwindowstoo. The generatedconfig.hstops claimingHAVE_STRINGS_H/HAVE_MEMORY_H:lib/common.hwould include<strings.h>, which MSVC's headers lack, and nothing inlib/uses a function from either header.HAVE_ARC4RANDOM_BUF=1, which assumes glibc 2.36+. On the aarch64 sysrootKey.cthen calls an undeclaredarc4random_buf(-Wimplicit-function-declaration, an error under C11). It now declaresHAVE_GETENTROPY(glibc 2.25+) andHAVE_SYS_RANDOM_H, soKey.cuses its ownarc4random_bufemulation overgetentropy.Failing runs before the change: macOS and Windows at install (
compat:fribidi@1.0.16 has no build for …), ubuntu-24.04-arm atcompat.xdmcp'sKey.c:96.