Skip to content

Rebuild native UI binaries - #49

Merged
SimonCropp merged 1 commit into
simon/gifted-zhukovsky-4c8444from
native-binaries-simon/gifted-zhukovsky-4c8444
Oct 10, 2026
Merged

SimonCropp merged 1 commit into
simon/gifted-zhukovsky-4c8444from
native-binaries-simon/gifted-zhukovsky-4c8444

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Rebuilt buildmonitor_ui from native/ for the four RIDs that load one.
Windows is not among them: that head renders with WinForms.

Produced by the build-native workflow from ea3f451.

@SimonCropp
SimonCropp merged commit 988913e into simon/gifted-zhukovsky-4c8444 Oct 10, 2026
@SimonCropp
SimonCropp deleted the native-binaries-simon/gifted-zhukovsky-4c8444 branch October 10, 2026 21:55
SimonCropp added a commit that referenced this pull request Oct 10, 2026
* Stop the Linux library needing glibc 2.38

build-native built libbuildmonitor_ui.so on the runner's own Ubuntu 24.04. A
library records the glibc symbol versions of the headers it was compiled
against, and the committed ones need GLIBC_2.38, for __isoc23_sscanf, fmod and
fmodf, and GLIBCXX_3.4.29. The loader refuses that on Ubuntu 22.04, Debian 12
and RHEL 8 and 9, so the Linux head could not open a window there and
BuildMonitor exited.

It is now built in a manylinux_2_28 container by native/build-linux.sh, the
way DiffEngine builds its viewer's, and the workflow checks the result rather
than trusting it: nothing above GLIBC_2.28, and nothing recorded as needed
outside a short list. That container's linker records every library it is
handed, and raylib hands on libSM and libICE, which a stock Ubuntu lacks, so
the library is linked with --as-needed.

Built that way from this commit, the linux-x64 library needs nothing above
GLIBC_2.27 and GLIBCXX_3.4.21, and loads on the container's own glibc 2.28,
where the committed one is refused. The committed binaries are not changed
here: build-native rebuilds them and opens the PR.

* Rebuild native UI binaries (#46)

Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>

* Make the Linux head draw frames, read input and wait between them

raylib 6.0's CMake reads every SUPPORT_ flag in config.h into an option that
defaults to ON, including the ones config.h sets to 0 (raysan5/raylib#5844),
and CUSTOMIZE_BUILD skips config.h's own values. So
SUPPORT_CUSTOM_FRAME_CONTROL was on, and EndDrawing neither swapped the frame
onto the screen, polled input nor waited for the next one, all of which
bm_present leaves to it for a frame it draws. SUPPORT_BUSY_WAIT_LOOP was on
the same way, and WaitTime, which is how bm_present waits out a frame it does
not draw, spun for the whole of it.

Run under Xvfb with a window manager, the committed linux-x64 library leaves
the window black, takes no keys, and from the first input draws without a
pause, which under the software rasteriser is every core. With the window
hidden it uses 15% of a core. Built from this commit the window is drawn,
clicks and keys are acted on, an idle window costs 5% of a core and a hidden
one under 1%.

Switch both off, with every other flag config.h defaults to 0, the partial
busy wait, and SUPPORT_SCREEN_CAPTURE, whose F12 writes a screenshot into the
working directory when it is pressed while frames are being drawn. Of the
picture formats only PNG stays on: the four others config.h enables are
decoders nothing here calls.

PixelTests.PresentWaitsForTheNextFrame times sixty drawn presents in the
shown window. The pixel snapshots could never have noticed: a capture draws
into a texture and never reaches EndDrawing. It takes 70 ms against the
committed library and a second against this one.

The committed binaries are not changed here: build-native rebuilds them and
opens the PR.

* Keep the Linux loop running while the window is minimised

raylib's PollInputEvents waits for an event, rather than polling, for as long
as the window is minimised, unless FLAG_WINDOW_ALWAYS_RUN is set, and every
bm_present makes that call. So the managed loop stopped with the window in
the taskbar: the tray's icon and menu were no longer updated, no notification
was shown, a click on the tray was not read, and a window command from the
socket waited in its queue.

With the raylib flags fixed and this flag left off, a show sent to a
minimised window, which is what starting BuildMonitor a second time sends,
did nothing until an X event reached the window. With it on, the window comes
back.

* Run every macOS entry point in an autorelease pool

NSApplication.run drains a pool per event, but this head never calls it: the
managed loop calls in instead. With no pool pushed, objc4 parks everything
autoreleased in one it creates for the thread, which drains only when the
thread exits, and that is the main thread. So everything a frame autoreleased
stayed until the process exited, in a tray that runs for days.

Every entry point that touches AppKit now runs inside its own pool, as
DiffEngine's do, bm_pick_directory and the tray calls among them.

Not built or run: the Swift head cannot be built on Windows. The file parses
and type checks under Swift 5.10 against stubs of AppKit and of the rest of
the module.

* Probe a musl RID and nothing else for the native library

NativeResolver tried the framework's own RID and then linux-{arch}, which is
the glibc build, so on Alpine the probe that was meant to miss found a
library after all. A musl RID now yields itself alone, as DiffEngine's
resolver does.

* Rebuild native UI binaries (#49)

Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant