cmake: support building a shared SDL3 DOS executable#15459
Draft
madebr wants to merge 4 commits intolibsdl-org:mainfrom
Draft
cmake: support building a shared SDL3 DOS executable#15459madebr wants to merge 4 commits intolibsdl-org:mainfrom
madebr wants to merge 4 commits intolibsdl-org:mainfrom
Conversation
Contributor
|
See #15377 (comment) for a solution about missing libc symbols in SDL3.dxe: Might be implemented in SDL_main for dos. These are the missing symbols in my gcc-3.4 build - dxe generated like: DetailsAs for exporting only the SDL symbols: dxe3gen from cvs has support |
Just chiming in to mention: I have an Ubuntu PPA for the djgpp toolchain, specifically for Github Actions and other CI. It includes dxe3gen (and libc and other utils) built from CVS sources. This may be useful here. https://launchpad.net/~jwt27/+archive/ubuntu/djgpp-toolchain |
sezero
reviewed
Apr 25, 2026
sezero
reviewed
Apr 25, 2026
Contributor
|
P.S.: I can't build this branch at all: linkage fails with unrecognized switch |
Contributor
Author
I pushed a change that filters it out. |
Contributor
Still no joy: Here is the tar ball of my configuration directory: This was with cmake-3.18. Curiously, cmake-4.0 works OK... |
Contributor
Author
|
Latest version I pushed works again for me, and is also valid c++. |
Contributor
Author
I'm using this property, which is 3.21+. Perhaps that's it. I'll add a CMake version check. No wait, I use generator expressions as arguments. I need 3.27. |
Contributor
Author
|
Apply this patch to see the actual --- a/build-scripts/djgpp-dxe-linker-wrapper.py
+++ b/build-scripts/djgpp-dxe-linker-wrapper.py
@@ -70,6 +70,10 @@ if not "-nostlib" in original_linker_args:
os.environ["DXE_LD_LIBRARY_PATH"] = "dontcare"
os.environ["DJDIR"] = "dontcare"
+print("dxe3gen command:")
+import pprint
+pprint.pprint(dxe3gen_command)
+
process_result = subprocess.run(dxe3gen_command)
raise SystemExit(process_result.returncode) |
Contributor
Here goes, from a cmake-4.0 run: Details |
Contributor
Author
Ignoring absolute paths, that's identical to mine. |
Contributor
|
P.S.: I get these annoying warnings from SDL_test_common.c: DetailsReason is djgpp int32_t is long, but that source doesn't include inttypes.h, |
Contributor
Author
|
Contributor
Author
|
Is this a valid patch? Or completely inappropriate use of --- a/include/SDL3/SDL_stdinc.h
+++ b/include/SDL3/SDL_stdinc.h
@@ -774,23 +774,35 @@ typedef Sint64 SDL_Time;
#ifdef PRId32
#define SDL_PRIs32 PRId32
#else
+#ifdef __ILP32__
+#define SDL_PRIs32 "ld"
+#else
#define SDL_PRIs32 "d"
#endif
#endif
+#endif
#ifndef SDL_PRIu32
#ifdef PRIu32
#define SDL_PRIu32 PRIu32
#else
+#ifdef __ILP32__
+#define SDL_PRIu32 "lu"
+#else
#define SDL_PRIu32 "u"
#endif
#endif
+#endif
#ifndef SDL_PRIx32
#ifdef PRIx32
#define SDL_PRIx32 PRIx32
#else
+#ifdef __ILP32__
+#define SDL_PRIx32 "lx"
+#else
#define SDL_PRIx32 "x"
#endif
#endif
+#endif
#ifndef SDL_PRIX32
#ifdef PRIX32
#define SDL_PRIX32 PRIX32 |
Contributor
No, it doesn't look correct to me. |
Contributor
Why don't we explicitly require C99+ for SDL_test, like we do for the normal sources? |
Contributor
Author
I guess because SDL_test did not see much development that required the more convenient c99. Uint32 c = 42;
SDL_Log("Uint32 c = %" SDL_PRIu32, c); |
Contributor
I say we should
That's user code where user can explicitly include inttypes.h, or define |
Contributor
Author
|
Doing the |
Contributor
An |
This fixes a compile warning when using the output of SDL_Swap32
directly using the SDL_PRIu32 macro in C90 mode:
testplatform.c:158:17: warning: format '%lX' expects argument of
type 'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
158 | SDL_Log("Value 32 = 0x%" SDL_PRIX32 ", swapped = 0x%" SDL_PRIX32,
|
sezero
reviewed
Apr 26, 2026
sezero
reviewed
Apr 26, 2026
| SDL_AddCommonCompilerFlags(SDL3_test) | ||
| target_compile_definitions(SDL3_test PRIVATE "$<$<CONFIG:Debug>:DEBUG>") | ||
| if("c_std_99" IN_LIST CMAKE_C_COMPILE_FEATURES) | ||
| target_compile_features(SDL3_test PRIVATE c_std_99) |
Contributor
There was a problem hiding this comment.
I suggest that you apply this already, w/o this P/R
Contributor
|
Just tested draw.exe and platform.exe under dosbox 0.74: they run. P.S.: Adapting the following to your python ld wrapper: grep SDL_ ../src/dynapi/SDL_dynapi.sym | sed -e s/SDL_/_SDL_/g | sed -e s/\;//g > SDL3.exp... and adding |
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
3 participants
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.
This adds supports for building SDL3 as a "dynamically loadable executable module" (dxe) using
dxe3gen. This util is usually part of a djgpp toolchain.Everything builds and links, but there is one small, not insignificant problem: starting the test executables fail immediately with a page fault.
With this pr I hope DOS specialists can find out what's wrong with my approach.
At the bottom of this message, I've posted a small script showing the steps needed to build and use a DOS module.
My implementation works by wrapping the linker with the
build-scripts/djgpp-dxe-linker-wrapper.pypython script.The scripts modifies the linker arguments to ones that
dxe3gencan handle (for-Yfor the import library.Because of linker errors, I have to explicitly add
-lcandcrt0.oto the linker arguments. Perhaps that's part of the reason it's currently failing?Steps to create and use a dxe module:
In DOS, you can now use
main.exewhich will automatically loadmodule.dxe.