Of the ports which depend on libsdl2_mixer, blobwars, starfighter, and gdash build but do not launch. lpairs2 launches and the freezes (no sound). Freeciv is the success story - it builds and appears functional with sound. My guess is that this indicates Tiger and the outdated libsdl2_mixer version are not the problem. Perhaps being big endian or PowerPC are problems. If anyone wants to test any of the four ports that build but don't work on Leopard or Snow Leopard PPC, it would be an interesting test for whether the ports don't support PPC, or if this is an outdated version or Tiger issue.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SDL2 for older MacOS X
- Thread starter lauland
- Start date
- Sort by reaction score
Check if failing ones need joystick. Certainly some of SDL deps in MacPorts do, and those fail on launch.
Apologies, was taking a break from SDL for a while. I had this tab open, but it was buried and I just dug it out.
I don't have either of those systems, so would mostly be guessing, but they would be educated guesses. When you say "not work correctly", you do mean that the ports build, but are having trouble running, correct? You are probably right about it being OpenGL...
10.5.8 ppc64: First guess would be 64 bit ints, the code should be 32 bit clean, but the ppc part may not be. Second, we know Apple did some tricks and the OS will report things a little differently on 64 bit cpus. For one, the ConditionalMacros.h (or related), at least on Tiger, reports things differently. Or I may be misreading things, is it specifically with 10.5.8 ppc64, but 10.6.8 ppc64 is ok?
10.6.8 ppc with ATI: If it works on ones without ATI, would definitely be OpenGL. It is probably not getting the right libs, ATI is likely overriding some of the system ones. This might be tricky, and you might need to special case ATI...but you might also be able to pass the right lib on command line. But...even then...the OpenGL code may be doing something a little squirrelly that isn't totally legit for the ATI implementation of OpenGL. We already know it was doing goofy things even in the base case.
Going to go back and read what you guys have been saying...
I don't have either of those systems, so would mostly be guessing, but they would be educated guesses. When you say "not work correctly", you do mean that the ports build, but are having trouble running, correct? You are probably right about it being OpenGL...
10.5.8 ppc64: First guess would be 64 bit ints, the code should be 32 bit clean, but the ppc part may not be. Second, we know Apple did some tricks and the OS will report things a little differently on 64 bit cpus. For one, the ConditionalMacros.h (or related), at least on Tiger, reports things differently. Or I may be misreading things, is it specifically with 10.5.8 ppc64, but 10.6.8 ppc64 is ok?
10.6.8 ppc with ATI: If it works on ones without ATI, would definitely be OpenGL. It is probably not getting the right libs, ATI is likely overriding some of the system ones. This might be tricky, and you might need to special case ATI...but you might also be able to pass the right lib on command line. But...even then...the OpenGL code may be doing something a little squirrelly that isn't totally legit for the ATI implementation of OpenGL. We already know it was doing goofy things even in the base case.
Going to go back and read what you guys have been saying...
Last edited:
Everything builds, but nothing works on a) 10.6.8 A5 image (both with ATI and Nvidia GPU) and b) 10.5.8 ppc64 with ATI GPU.
I keep forgetting, perhaps I did not verify 10.6.8 Nvidia image with ATI GPU (this is not a crazy combo, since Nvidia image just uses newer OpenGL and related graphics components from 10a190 image, while A5 image uses 10.5.8 replacements).
10.6.8 has no support for ppc64, so only 10.5.8 is relevant for this.
From the other thread you provided some output from running mpv, seemingly on 10.6.8, both x11 and cocoa versions. The x11 one's log specifies a missing ARB extension, so it is likely whatever OpenGL driver/libs you were using doesn't have that extension, and the x11 opengl driver requires it.
I will look at the code to see how that extension is used. Last time I looked, it seemed to require several extensions that may or may not have been completely necessary (and just fail if they aren't all present). If that particular one is used, we might modify the driver to not use it. If that is the case, I could do all that even on my Tiger machine, since it is just in the SDL2 video driver.
From what I know (and I may be wrong), opengl context profiles are important for having multiple drawing environments at the same time, so possibly when more than one window is used, or, if you are doing two different kinds of drawing to the same window. We might be able to work around this, or do it in a different way.
The non-x11 one seems to quit early in the video driver init, and there is no other useful messages.
The video drivers in SDL2 tend to be very conservative, and will just give up and quit if they find (or don't find) ANYTHING outside of what they expect.
Like x11 and the ARB extension, the cocoa driver may be checking and failing for something that isn't completely necessary (or could be worked around). It wouldn't be the same exact thing, as that is a GLX extension which is part of x11, but there's a high chance it is something related.
One final note, since that is GLX, it is probably just the opengl driver implementation (specifically the x11 interface to it), and not something the card itself doesn't support.
I will look at the code to see how that extension is used. Last time I looked, it seemed to require several extensions that may or may not have been completely necessary (and just fail if they aren't all present). If that particular one is used, we might modify the driver to not use it. If that is the case, I could do all that even on my Tiger machine, since it is just in the SDL2 video driver.
From what I know (and I may be wrong), opengl context profiles are important for having multiple drawing environments at the same time, so possibly when more than one window is used, or, if you are doing two different kinds of drawing to the same window. We might be able to work around this, or do it in a different way.
The non-x11 one seems to quit early in the video driver init, and there is no other useful messages.
The video drivers in SDL2 tend to be very conservative, and will just give up and quit if they find (or don't find) ANYTHING outside of what they expect.
Like x11 and the ARB extension, the cocoa driver may be checking and failing for something that isn't completely necessary (or could be worked around). It wouldn't be the same exact thing, as that is a GLX extension which is part of x11, but there's a high chance it is something related.
One final note, since that is GLX, it is probably just the opengl driver implementation (specifically the x11 interface to it), and not something the card itself doesn't support.
You can use clang on 10.5+ if not 10.4+, but not on powerpc. However mesa only uses llvm, AFAIU.
We actually have a newer libcxx on powerpc in my ports, but that is not required for mesa or llvm. Also, if you use libcxx, it should be used for everything, which means rebuilding all C++ ports.
@Wowfunhappy You might be able to install ports with libc++, if you set `cxx_stdlib libc++` in `macports.conf`. This is experimental, but it works: https://macos-powerpc.org/packages_libcxx/
More info: https://github.com/macos-powerpc/powerpc-ports/issues/4
More info: https://github.com/macos-powerpc/powerpc-ports/issues/4
@lauland This can be tried out: https://github.com/macos-powerpc/powerpc-ports/commit/06c3937dab00957b2872c02aa2d908222c54218f
I only enabled it by default on 10.6, so for anything earlier, in order to test it, build as `mesa +llvm`.
Upd. There is some funny nonsense to be addressed with llvm:
This on on powerpc. I have disabled +llvm by default for the time being.
I only enabled it by default on 10.6, so for anything earlier, in order to test it, build as `mesa +llvm`.
Upd. There is some funny nonsense to be addressed with llvm:
Code:
LLVM ERROR: Scattered relocations not supported for MachO AArch64
Last edited:
That ppc llvm error is odd..."AArch64" is referring to Arm64 cpus. Shouldn't be seeing that on powerpc, maybe it is trying to build a cross compiler, or has the arch wrong?
FYI The OpenGL ARB error you saw with mpv seems to be from mpv, and not SDL2. I didn't find anywhere in SDL2 where it explicitly required that extension, nor did I find that particular error message. So mpv must has OpenGL calls in it and call it directly.
You might want to run "glxinfo" and compare on one of the machines where it works with one it doesn't...seems ati vs nvidia, right? glxinfo should come with an OpenGL, no idea if apples vs macports, etc. Anyway, it will show ALL the extensions the currently running glx (X11's OpenGL) supports. My guess is you'll see that particular profile ARB extension missing on the mac with the problem.
In other words, it doesn't look like something that can be fixed in SDL2, but would have to be mpv...at least that is my theory.
FYI The OpenGL ARB error you saw with mpv seems to be from mpv, and not SDL2. I didn't find anywhere in SDL2 where it explicitly required that extension, nor did I find that particular error message. So mpv must has OpenGL calls in it and call it directly.
You might want to run "glxinfo" and compare on one of the machines where it works with one it doesn't...seems ati vs nvidia, right? glxinfo should come with an OpenGL, no idea if apples vs macports, etc. Anyway, it will show ALL the extensions the currently running glx (X11's OpenGL) supports. My guess is you'll see that particular profile ARB extension missing on the mac with the problem.
In other words, it doesn't look like something that can be fixed in SDL2, but would have to be mpv...at least that is my theory.
It is obviously wrong, but I could not find any mention of this message in mesa itself, and LLVM 7 should not have arm64 support, so it is weird. Will look into that when get time to.
SDL2 with Cocoa does not work in 10.6.8 A5 image for me at all, with any apps tried and on Nvidia and ATI alike.
That's awesome! How do we do that? I got Desmume to compile on Tiger, but it fails to launch because of lack of joystick support. If I can test it with the dummy and it functions, I will make a Portfile.
Check libsdl2-x11 port. I will do the same for -cocoa today.
This is wiliwili client using SDL2 on 10.6.8, which had that issue (and which led me to fixing it finally):
Thanks for your work! We now have a more recent version of Desmume for PowerPC Macs than Macintosh Garden has. This version is not compiled with any optimizations, so there will be work to be done before I submit the Portfile, but it is still wild this launches.
Attachments
The error originates from https://github.com/iains/LLVM-7-bra...d/Targets/RuntimeDyldMachOAArch64.h#L284-L285
So it is not even in Mesa as such. See: https://github.com/iains/LLVM-7-branch/issues/10
MPV upstream made quite an effort to break opengl LOL
vo_opengl: cleanups after vo_opengl_old removal · mpv-player/mpv@e349579
Don't load all the legacy functions (including ancient extensions). Slightly simplify function loader and context creation, now that legacy GL doesn't need to be handled. Remove the code fo...
github.com
vo_gpu: context_glx: remove legacy create_context_x11_old() · mpv-player/mpv@e869d51
The old/legacy code-path isn't really needed for mpv use-cases. In particular: All Mesa drivers (even GL 2.1 ones like lima/vc4) work fine with the "non-legacy" path. From propriet...
github.com
Great news about getting the joystick driver to work with newer SDL2!
So is there anything in particular you'd want me to look at?
I'd consider installing 10.6.8 ppc on one of my machines if it were easy enough...then could look at cocoa driver possibly.
So is there anything in particular you'd want me to look at?
I'd consider installing 10.6.8 ppc on one of my machines if it were easy enough...then could look at cocoa driver possibly.
Specifically with SDL perhaps just get a newer Cocoa working.
There are issues with GL to address with mpv, but mpv does not build on 10.4. It uses SDL2 for video output, but the code in mpv itself needs some fix-ups. Besides of what I referred to above, there is an issue with wrong colors on BE, see: https://github.com/xfangfang/wiliwili/issues/570 (this is a very nice app, worth fixing).
I think it is easy enough. I have re-installed it from scratch multiple times recently.