Makefile: let platform=unix build without OpenGL - #215
Open
sunlollyking wants to merge 1 commit into
Open
Conversation
The unix platform links -lGL and sets HAVE_OPENGL=1 unconditionally on x86 and x86_64, so the core cannot be built for a system that provides only OpenGL ES. There is no GLES fallback to reach for either: Makefile.common gates the renderer on HAVE_OPENGL and compiles glsym_gl.c, and the HAVE_OPENGLES3 the platform table sets for the ARM boards is never read by anything. Add DISABLE_OPENGL so those systems can build the software renderer, which is what they would end up using in any case: make platform=unix DISABLE_OPENGL=1 A separate variable rather than HAVE_OPENGL=0, because HAVE_OPENGL is initialised to 0 at the top of this file and so is already 0 when the platform block is evaluated. Default behaviour is unchanged.
sunlollyking
force-pushed
the
allow-building-without-opengl
branch
from
August 7, 2026 14:14
90fedee to
fab8107
Compare
sunlollyking
added a commit
to sunlollyking/LibreELEC.tv
that referenced
this pull request
Aug 10, 2026
melonDS is a Nintendo DS emulator. Its libretro core is desktop-GL only -- the renderer is gated on HAVE_OPENGL and compiles glsym_gl.c, and the HAVE_OPENGLES3 its platform table sets is never read -- so it takes OpenGL where the project provides it and the software renderer everywhere else. DS runs well on the latter, which is what the ARM targets would have been getting in any case. The patch adding DISABLE_OPENGL is submitted upstream as libretro/melonDS#215
kel-mo
added a commit
to kel-mo/tv.kodi.Kodi
that referenced
this pull request
Aug 16, 2026
Port the new libretro cores from LibreELEC PRs #11656 (melonDS, Yaba Sanshiro) and #11668 (Dolphin). melonDS builds the software renderer only: its OpenGL renderer is desktop-GL only and useless under a GLES Kodi. Carries the pending upstream patch (libretro/melonDS#215) adding DISABLE_OPENGL, and links with -Wl,-z,noexecstack so Kodi can dlopen a core whose assembly lacks GNU-stack notes. Yaba Sanshiro builds its GLES path via FORCE_GLES=1; its core is pinned to the yabasanshiro branch head of libretro/yabause. Dolphin builds with USE_SYSTEM_LIBS=ON instead of its vendored Externals. The freedesktop 25.08 runtime provides most of them (fmt, glslang, xxhash, zlib, zstd, lz4, lzo2, bzip2, xz, curl, libusb); enet, libspng, minizip-ng, mbedtls 2.28 (dolphin requires the 2.28 branch), SFML 3.0.x (3.1 grew a hard libssh2 dependency the runtime lacks; checker constrained below it) and hidapi are added as dependency modules. The only vendored code left is dolphin's own in-tree glue plus six pinned header/wrapper submodules (imgui, implot, tinygltf, watcher, cpp-ipc, cpp-optparse) that have no system equivalent. Core commits match each kodi-game addon's depends pin. Dolphin's Sys support data (its own redistributable free DSP ROM and font replacements, per-game settings) is installed from the core source into the addon's install path resources, giving a working core with no user setup: Kodi hands that directory to the core when the profile resources dir is empty, and dolphin's writes go to the libretro save dir. Vulkan and X11 are off; RetroPlayer is GL/GLES only. Verified at runtime on x86_64: dolphin boots GameCube titles and, with the RetroPlayer hardware rendering PR stack, is fully playable.
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.
platform=unixlinks-lGLand setsHAVE_OPENGL=1unconditionally on x86 andx86_64:
So the core cannot be built at all for a system that provides only OpenGL ES —
the link fails with
cannot find -lGL.There is no GLES fallback to reach for instead.
Makefile.commongates therenderer on
HAVE_OPENGLand compilesglsym_gl.c, and theHAVE_OPENGLES3that the platform table sets for the ARM boards (
rpi4_64,odroidc4andfriends) is never read by the build or by any source — those targets link
-lGLESv2but build the software renderer regardless.glsym_es3.cships inthe vendored libretro-common but is never added to
SOURCES_C.This adds
DISABLE_OPENGLso such systems can build the software renderer,which is what they would end up running in any case:
Why a new variable and not
HAVE_OPENGL=0That was my first attempt and it is wrong.
HAVE_OPENGL := 0is set at the topof the Makefile, so it is already
0when the platform block is evaluated — aguard of
ifneq ($(HAVE_OPENGL), 0)never passes, and OpenGL ends up disabledfor everyone. A separate opt-out variable avoids the ordering entirely.
Verified
With
ARCH=x86_64, comparingmake platform=unix -nbefore and after:-lGLlinkedGPU_OpenGLobjectsDISABLE_OPENGL=1Also built and installed end to end against a GLES-only sysroot.
Found packaging melonDS for LibreELEC, whose default x86_64 image is GLES-only.