ok, tested and works almost fine, except that the x86_64 built on Lion (SDK 10.7 or 10.6 - tried both) crashes on Snow Leopard on switching to fullscreen with a segfault. This used to work with hg when the fullscreen Lion fix was for all OS X platforms.
Gregory, as I wrote earlier in this thread, Jeremys patch also has problems with x86_64 builds on Snow Leopard. To avoid this both SDL and your app need to be build against the 10.6 SDK if you build it on Lion. Otherwise it will crash on going fullscreen on Snow Leopard. Also Jeremys patch seems to be incomplete, missing the ERR_DOUBLEBUFF define, probably in SDL_QuartzVideo.h.
With SDL’s testalpha I made the same test. SDL and test alpha compiled
against SDK 10.7 makes test alpha -fullscreen crash on SL with a segfault.
Are you specifying a minimum SDK version when you build with the 10.7
SDK, or just building against 10.7?
If you don’t tell it you want backwards compatibility, then SDL is doing
the right thing and dropping the pre-10.7 support. The build compiled
against the 10.4 SDK happens to work with 10.7 because of (mostly)
forward compatibility.
You should add this to your SDL build command line…
-mmacosx-version-min=10.4
IDEALLY, you build against whatever the newest SDK you have is, and tell
it that you want to target as far back as 10.4 (in practice, this
doesn’t work, because using a newer SDK inserts Mach-O load commands in
your binary that fail on older releases…the true solution involves
figuring out how to stop that from happening and then never looking at
the 10.4 SDK again).
–ryan.
I’m using that for the PPC and 32bit build (where I found out the other day that using the 10.5 SDK and specifying minimum SDK 10.4 works fine). The 64bit builds I did with just pointing at my prefix in the cflags and lflags and curiosly that used to work before for 64bit SDL and 64bit builds of the apps I do snapshots for. That’s why I was surprised that this broke suddenly.
But what you wrote makes sense, probably I encountered a fluke before 
So I’d better use the minimum SDK in the future. Got to try out how the 10.7 SDK works with min version 10.6 on OSX 10.6. The 10.6 SDK didn’t fare to well on OSX 10.5 when I tried that.
Thanks for the explanation.
Dom
Btw, I’m using the forum to write and wonder if my replies are looking ok on the ML or whether I should follow some guidelines to make them more readable on the ML (since I presume that Forum posts are posted to the ML as well).
Ryan C. Gordon wrote:>
With SDL’s testalpha I made the same test. SDL and test alpha compiled
against SDK 10.7 makes test alpha -fullscreen crash on SL with a segfault.Are you specifying a minimum SDK version when you build with the 10.7
SDK, or just building against 10.7?If you don’t tell it you want backwards compatibility, then SDL is doing
the right thing and dropping the pre-10.7 support. The build compiled
against the 10.4 SDK happens to work with 10.7 because of (mostly)
forward compatibility.You should add this to your SDL build command line…
-mmacosx-version-min=10.4
IDEALLY, you build against whatever the newest SDK you have is, and tell
it that you want to target as far back as 10.4 (in practice, this
doesn’t work, because using a newer SDK inserts Mach-O load commands in
your binary that fail on older releases…the true solution involves
figuring out how to stop that from happening and then never looking at
the 10.4 SDK again).–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I’m using that for the PPC and 32bit build (where I found out the other
day that using the 10.5 SDK and specifying minimum SDK 10.4 works fine).
The 64bit builds I did with just pointing at my prefix in the cflags and
lflags and curiosly that used to work before for 64bit SDL and 64bit
builds of the apps I do snapshots for. That’s why I was surprised that
this broke suddenly.
We’re pretty aggressive about removing deprecated APIs now, so if you’re
using the 10.7 SDK and don’t explicitly ask for compatibility with
earlier versions, we #ifdef out deprecated functionality. This is fairly
new for SDL, but since Apple made that one thing in 10.7 not just
deprecated, but a definite crash, we’re trying to protect against these
sort of things now. This wasn’t something we’ve tried before this last
round of Lion fixes, though.
BTW: the thing about the Mach-O load command that doesn’t work on older
OSes? It turns out you need to use -mmacosx-version-min=10.4 on the
linker command line too. I just built a Hello World app against the 10.6
SDK, with Xcode 3.2, which causes this problem when you run the app on
10.5…if I make sure it links with that command line, the problem goes
away. Which–pending more testing–might mean it’s safe to move to 10.7
and Xcode 4, even if you still need to target Mac OS X 10.4.
(I can’t speak to PowerPC support here, though.)
(Also, my apologies to Apple, because I’ve been blaming them for months
over something that seems to be fixable with a command line argument.)
Btw, I’m using the forum to write and wonder if my replies are looking
ok on the ML or whether I should follow some guidelines to make them
more readable on the ML (since I presume that Forum posts are posted to
the ML as well).
I’m using the mailing list exclusively, and it looks fine here.
–ryan.
Ryan C. Gordon wrote:
I’m using that for the PPC and 32bit build (where I found out the other
day that using the 10.5 SDK and specifying minimum SDK 10.4 works fine).
The 64bit builds I did with just pointing at my prefix in the cflags and
lflags and curiosly that used to work before for 64bit SDL and 64bit
builds of the apps I do snapshots for. That’s why I was surprised that
this broke suddenly.We’re pretty aggressive about removing deprecated APIs now, so if you’re
using the 10.7 SDK and don’t explicitly ask for compatibility with
earlier versions, we #ifdef out deprecated functionality. This is fairly
new for SDL, but since Apple made that one thing in 10.7 not just
deprecated, but a definite crash, we’re trying to protect against these
sort of things now. This wasn’t something we’ve tried before this last
round of Lion fixes, though.
Thanks, that explains it nicely
BTW: the thing about the Mach-O load command that doesn’t work on older
OSes? It turns out you need to use -mmacosx-version-min=10.4 on the
linker command line too. I just built a Hello World app against the 10.6
SDK, with Xcode 3.2, which causes this problem when you run the app on
10.5…if I make sure it links with that command line, the problem goes
away. Which–pending more testing–might mean it’s safe to move to 10.7
and Xcode 4, even if you still need to target Mac OS X 10.4.
Got to try this out. I think I did use that on the linker line before, too, when compiling Exult. But then probably ran into an incompatibility because I had compiled SDL against a different SDK. So I never succeeded in compiling Exult in 32bit against SDK 10.6 and now 10.7 and being able to run it on 10.5.
Will try now more thoroughly
(I can’t speak to PowerPC support here, though.)
Yup, for PPC you do need Xcode 3.2x in some folder, point to the old compiler and you need to define --host=powerpc-apple-darwin on configure for everything you want to compile in ppc. Xcode 4 itself cannot be made to compile ppc code at all, if I’m not mistaken…
Dominus wrote:
BTW: the thing about the Mach-O load command that doesn’t work on older
OSes? It turns out you need to use -mmacosx-version-min=10.4 on the
linker command line too. I just built a Hello World app against the 10.6
SDK, with Xcode 3.2, which causes this problem when you run the app on
10.5…if I make sure it links with that command line, the problem goes
away. Which–pending more testing–might mean it’s safe to move to 10.7
and Xcode 4, even if you still need to target Mac OS X 10.4.
Got to try this out. I think I did use that on the linker line before, too, when compiling Exult. But then probably ran into an incompatibility because I had compiled SDL against a different SDK. So I never succeeded in compiling Exult in 32bit against SDK 10.6 and now 10.7 and being able to run it on 10.5.
Will try now more thoroughly
hmm, that failed. Seems that Exult links to libstdc++ and when I compile it against SDK 10.7 on Lion it expects something on Leopard in /usr/lib/libstdc++.6.dylib which isn’t there 
Of course on Lion it compiles against libstdc++.6.0.9 but on Leopard you have libstdc++.6.0.4
Dyld Error Message:
Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
Referenced from: /Users/hansdampf/Desktop/Exult.app/Contents/MacOS/exult
Expected in: /usr/lib/libstdc++.6.dylib