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.
Finally looking into this. Used previous image of Leopard 10.5.4 on my G4, that I've always used in the past, and tried to build/run SDL 2.0.3 (cocoa) and 2.32.4 (x11), using same source tarballs as I had in Tiger (so no macports, and no updates since Summer), and immediately ran into problems with the OpenGL part of Apple's X11. (Also built SDL 1.2 as sanity test, with some similar issues).
Tried clean install of both 10.5.4 and 10.5.0 from original Apple media, to rule out disk image, and no difference. Updating to 10.5.8, and newer XQuartz helped a lot (with build, if not running), but still having weirdness. Trying macports X11 seems a logical next step.
Did sanity check of building same sources on updated but fresh install of PPC Tiger, and saw no issues at all.
Also going to try same source on Intel, 10.4-10.6. Hopefully this will help at least rule out some things, for what you seen've on your systems.
Tried clean install of both 10.5.4 and 10.5.0 from original Apple media, to rule out disk image, and no difference. Updating to 10.5.8, and newer XQuartz helped a lot (with build, if not running), but still having weirdness. Trying macports X11 seems a logical next step.
Did sanity check of building same sources on updated but fresh install of PPC Tiger, and saw no issues at all.
Also going to try same source on Intel, 10.4-10.6. Hopefully this will help at least rule out some things, for what you seen've on your systems.
Last edited:
Interesting. To be clear, are these build failures or runtime failures (update: from “with build, if not running” apparently build ones initially)? AFAIU, Apple X11 contains both X11 libs and X server (while in MacPorts these are completely separate ports). It may be useful to know further details on what specifically is failing.
Besides, MacPorts had before an option to use system X11, I think, and in any case it is possible to implement, but it won’t go along with reproducible builds.
Problems with both build AND run. Got "ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib" building, but an XQuartz update fixed it.
Turns out the OpenGL part of of X11 on Leopard (stock installs, or "XQuartz") doesn't seem to support Rage 128 cards well or at all. The Cocoa driver in 2.0.3 and 1.2 was fine. On older X11 it just uses the software renderer, so works but very slow. With an updated XQuartz (2.3.3.2, the one that fixed the linker error) I get:
leopard:~ lauland$ glxinfo
name of display: :0.0
X Error of failed request: GLXBadContext
Major opcode of failed request: 0 ()
Serial number of failed request: 16
Current serial number in output stream: 16
(Even latest avail XQuartz for Leopard, 2.6.x does this)
Tested on ibook g4, tibook, and g4 mini, which all had various Radeons and all work fine. Put a Radeon 7000 in the G4 and now it works too.
There's a minor problem in "testnative" for SDL 2.0.3 that I'll probably see about fixing, but otherwise, if you update your XQuartz, and have at least a Radeon, all three SDL versions (1.2, 2.0.3, and 2.32) work fine on PPC Leopard with no changes.
Don't know if macport's X11 would be any better for Leoppard on Rage 128 cards, not worth the time to try at the momement for me.
At one point I think you had some SDL2 trouble on a machine running Leopard, correct? You should try different versions of X11, but definitely make sure "glxinfo" doesn't give you an error. (In other words, the problem may be a video card driver or X11, and not SDL2 at all).
Will next test on intel, including Intel Snow Leopard.
Turns out the OpenGL part of of X11 on Leopard (stock installs, or "XQuartz") doesn't seem to support Rage 128 cards well or at all. The Cocoa driver in 2.0.3 and 1.2 was fine. On older X11 it just uses the software renderer, so works but very slow. With an updated XQuartz (2.3.3.2, the one that fixed the linker error) I get:
leopard:~ lauland$ glxinfo
name of display: :0.0
X Error of failed request: GLXBadContext
Major opcode of failed request: 0 ()
Serial number of failed request: 16
Current serial number in output stream: 16
(Even latest avail XQuartz for Leopard, 2.6.x does this)
Tested on ibook g4, tibook, and g4 mini, which all had various Radeons and all work fine. Put a Radeon 7000 in the G4 and now it works too.
There's a minor problem in "testnative" for SDL 2.0.3 that I'll probably see about fixing, but otherwise, if you update your XQuartz, and have at least a Radeon, all three SDL versions (1.2, 2.0.3, and 2.32) work fine on PPC Leopard with no changes.
Don't know if macport's X11 would be any better for Leoppard on Rage 128 cards, not worth the time to try at the momement for me.
At one point I think you had some SDL2 trouble on a machine running Leopard, correct? You should try different versions of X11, but definitely make sure "glxinfo" doesn't give you an error. (In other words, the problem may be a video card driver or X11, and not SDL2 at all).
Will next test on intel, including Intel Snow Leopard.
Last edited: