Repository navigation
Rebuild native UI binaries - #46
Merged
Merged
Conversation
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> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
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>
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
1 participant
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.
Rebuilt
buildmonitor_uifromnative/for the four RIDs that load one.Windows is not among them: that head renders with WinForms.
Produced by the
build-nativeworkflow from b3b2dbf.