libsdl2: enable build for powerpc with x11 backend #19531
Closed
Conversation
This file contains 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
|
Notifying maintainers: |
macportsbot
added
type: bugfix
type: enhancement
maintainer: open
|
And does anything work when built against this? |
|
@kencu Any specific test-case to try out what matters? |
|
just pick any 10 random ports that use libsdl2 and have at it. There are many to choose from, but grab a few games, an emulator, etc. exercise video and sound, see what happens. Throw up a few screen grabs here. we all hope it works for you, but there is no point pushing something broken. |
|
@kencu Well, out of random ports a large chunk is explicitly broken either across the board or at least on old Intel, some require Qt5 and Java, other require fixing its dependencies. That is why I asked; a decisive test will be not that something random – of unknown status – fails, but verifying two specific issues:
Since you worked on SDL2 earlier, I expected you to be able to suggest some specific cases to test. P. S. For now, please do not suggest anything requiring joystick – it is disabled, which I explicitly mentioned and pointed out the reason. Until GCC upstream fixes the bug, I cannot determine whether joystick will work. |
|
A typical dependency of SDL: https://ports.macports.org/port/openrct2/details |
|
P. S. It could be possible though to build a generic module for joystick bypassing broken objective C. |
|
@kencu Responding to a removed comment: I have obviously tried some games and emulators yesterday, but they turned out to require joystick module. That is, they build, but complain about joystick on start. Since no one is interested to save my time by referring to cases known to work on 10.6 Intel, I will eventually find some via random search – which either meaningfully work or meaningfully fail (i.e. due to SDL and not unrelated issues). |
I'm aware of at least two, that should be working for 10.6 Intel: Have you tried either of those? |
|
@mascguy Thank you, this is helpful, I will check these once my |
|
UPD. All |
|
Here, I’ll restore my comment, now that you’ve responded to it anyway: “Yikes -- so far you can't find even one game using libsdl2 that will build on PPC to test this? How do you know if it works at all then?” Just pick any port that uses libsdl2 that ports.macports.org says works on 10.6. I have no idea which ones don’t use the joystick module, nor does anyone else. |
|
I see libsdl2 does come with an entire test suite… that would perhaps be a place to explore… |
|
@kencu In your old libsdl2 port for Leopard you replaced joystick with an earlier implementation (2.0.1). Do you think this might work here? Unless upstream suggest a better way, of course. |
@kencu Good suggestion. Let me switch the port to CMake, I already did that once for 2.0.22 earlier. (I won’t do that in PR, unless approved by others, but nothing prevents from doing it locally.) |
|
@mascguy |
|
@mascguy Looks like we do need joystick for games (and possibly emulators). |
|
UPD. I need to fix headers, they hardcode wrong paths to X11 libs, so Macports settings are ignored. |
|
Apparently some trickery needed to run a complete test suite, by default it runs only these: |
|
@kencu @mascguy Possibly, Mesa’s I will try that way; took quite a while to fix X11 with CMake build system – it is set up to sabotage it LOL. Also, sources hardcode wrong paths to X11, leading to nowhere, and that also breaks loading. |
|
@kencu By the way, any ideas what may cause that weirdness with Mesa’s |
|
@mascguy @kencu @jmroot What are your opinions on switching the port to CMake build system? Since I wanted to run tests, I switched to CMake locally (which was quite painful, since CMake code is apparently newer, and more things are broken for older macOS). So anyway, now it works fine, but I would prefer to avoid doing related fixes twice – for both build systems. Personally I am more comfortable with CMake, but besides that there are likely advantages:
|
Well, as you know, this is a decision of the maintainer (Josh). So it's up to him. As for use of CMake vs. GNU AutoTools, there are times where the latter is necessary. Particularly if a project's AutoTools-based build is more mature than their CMake version. And that appears to potentially be the case here, based on your experience. Ultimately the CMake build could be enhanced to support all of the legacy cases though. And if you were to submit a PR to upstream with such changes, there's a reasonable chance they'd accept them... |
|
@mascguy Got it. Well, build system is discussable. If we get meaningful results with X11 backend on PowerPC, I can make sure it works with Autotools after all. Biggest issue with testing is that dependents were never tested with GCC, forget on PowerPC, and many are broken to some extent. Some, like On a positive side, we get a few ports fixed in the process. |
libGL from mesa and libGL from Apple are not the same. Apple donated code to mesa to provide a mesa backend where GLX functions were directly translated to calls into Apple’s graphics drivers. So that is fast and tight…. So that is what you want to use with x11 software and mesa. GLX. Everything else is routed through a software rendered pathway and is both never tested and orders of magnitude slower. The world has moved on past GLX now, GLES, Wayland, etc, and as Apple uses Metal, not OpenGL, they are not providing OpenGL updates to mesa anymore for any of that. There is work being done to translate those newer OpenGL calls into Metal calls, but that is for current systems. |
|
@mascguy @kencu I have built |
|
@mascguy In fact here autotools are easier: less patching with the same result. I have updated the PR now to the version which has fixed paths. |
|
We can add up joystick a bit later. This should be mergeable, perhaps. |
|
Wrong color are caused by Mesa/OpenGL, apparently: |
|
@evanmiller Would you be interested to take a look? This should work eventually, but some fix-up is needed still. |
|
These changes also allow 10.5 Intel to use SDL2 with the proper modifications to the portfile, though I was not able to build with OpenGL. |
@Jazzzny Oh, could you please test it then, does it work correctly there? |
I was able to compile and use ffplay from ffmpeg, which heavily relies on SDL2, so I believe it does work correctly 🙂 |
|
@Jazzzny By the way, could you share what changes you made specifically? |
|
Pretty much just removing the PowerPC gatekeeping. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Well :)
Turned out, there is no point to fix an old
libsdl2-snowleopardport with X11 backend, the current version builds fine with the same patches. Essentially, those amount to reverting@autoreleasepoolclangisms.@mascguy @kencu
UPD. I have opened an issue with upstream re X11 backend and joystick module: libsdl-org/SDL#8021
Type(s)
Tested on
macOS 10.6
Xcode 3.2
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?