Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions pkgs/by-name/sd/SDL_compat/package.nix
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
{
lib,
SDL2,
sdl2-compat,
cmake,
darwin,
fetchFromGitHub,
libGLU,
libiconv,
libX11,
mesa,
pkg-config,
stdenv,
Expand Down Expand Up @@ -38,8 +39,11 @@ stdenv.mkDerivation (finalAttrs: {
autoSignDarwinBinariesHook
];

propagatedBuildInputs =
[ SDL2 ]
buildInputs =
[
libX11
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does libx11 come from here? Was it propagated by normal SDL2 or something?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was, see

dlopenPropagatedBuildInputs =
[ ]
# Propagated for #include <GLES/gl.h> in SDL_opengles.h.
++ lib.optional (openglSupport && !stdenv.hostPlatform.isDarwin) libGL
# Propagated for #include <X11/Xlib.h> and <X11/Xatom.h> in SDL_syswm.h.
++ lib.optionals x11Support [ libX11 ];

It might however make sense to do the following:

# SDL_compat
propagatedBuildInputs = sdl2-compat.propagatedBuildInputs ++ [ ... ];
# sdl2-compat
propagatedBuildInputs = sdl3.propagatedBuildInputs ++ [ ... ];

This adds extra complexity, but would allow us to not maintain multiple lists of the same thing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not quite familiar with how propagatedBuildInputs works, there might be better ways.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be necessary though, that's what propagation does already - if sdl2-compat is in sdl-compat's propagatedBuildInputs, sdl2's propagatedBuildInputs will also be propagated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thats the issue!!
See

buildInputs = [
sdl3
];

sdl2-compat is not listing sdl3 as propagated build input. THAT is the issue and should be fixed. Then explicit libX11 can be dropped here.

Copy link
Contributor

@K900 K900 Mar 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should, however, propagate libX11, because include/SDL2/SDL_syswm.h refers to xlib includes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sdl2-compat also does a dlopen on sdl3 at runtime, see #388079. The fact that is currently missing is more a mistake/bug than anything.
(these two PRs really should have been one, huh?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i need to do some testing. But either way, libX11 being in SDL_compat explicitly seems to not be the correct solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sdl2-compat also does a dlopen on sdl3 at runtime, see #388079. The fact that is currently missing is more a mistake/bug than anything.

But that is handled by rpath and doesn't really have to do with propagated build inputs, or am I missing something?

But either way, libX11 being in SDL_compat explicitly seems to not be the correct solution.

I'm still a bit fuzzy on how exactly propagated build inputs work but I don't understand why that wouldn't be the correct approach. It seems like sdl2-compat doesn't need to propagate libX11, since I've managed to build some games without it, but SDL1 does so that's why it appears here. It's a bit weird that SDL2 propagated libX11 but maybe that was the issue in the first place and now it got accidentally corrected in sdl2-compat?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SDL2 propagated libX11. If sdl2-compat is supposed to be a drop-in replacement, it should do the same imo.

sdl2-compat
]
++ lib.optionals stdenv.hostPlatform.isDarwin [
libiconv
Cocoa
Expand Down Expand Up @@ -67,14 +71,12 @@ stdenv.mkDerivation (finalAttrs: {
if stdenv.hostPlatform.isDarwin then
''
install_name_tool ${
lib.strings.concatMapStrings (
x: " -add_rpath ${lib.makeLibraryPath [ x ]} "
) finalAttrs.propagatedBuildInputs
lib.strings.concatMapStrings (x: " -add_rpath ${lib.makeLibraryPath [ x ]} ") finalAttrs.buildInputs
} "$lib"
''
else
''
patchelf --set-rpath "$(patchelf --print-rpath $lib):${lib.makeLibraryPath finalAttrs.propagatedBuildInputs}" "$lib"
patchelf --set-rpath "$(patchelf --print-rpath $lib):${lib.makeLibraryPath finalAttrs.buildInputs}" "$lib"
''
}
fi
Expand Down