Hi everyone,
After upgrading XCode from 4.4.1 to 4.5.2 (along with its CLI tools) I was able
to re-build both the 32bit (using 'make') and 64bit binaries (using
./make-macosx.sh).
I can agree and say that the 64bit build works fine while corruption/artifacts
occurs on the 32bit version.
Also, I installed the osx10.5+ SDL 1.2.15 framework from SDL's site.
Great to have it running on my MBP, BTW.. Thank you. :)
Vincent
----- Original Message -----
From: "Richard Allen" <r...@ra.is>
To: "Primary ioquake3 Discussion/Development list" <ioquake3@lists.ioquake.org>
Sent: Friday, December 28, 2012 6:03:50 AM
Subject: Re: [ioquake3] Can somebody try ioquake3 (head) 32bit on an nvidia mac?
Yes, I can confirm this corruption issue on 32bit builds using the SDL
Framework. I'm currently working with MAN-AT-ARMS on this issue and we've
figured some things out.
As far as I can see, using the Framework breaks everything but the x86_64
builds.
Now, the Framework system is something I still dont understand. When examining
/Library/Frameworks/SDL.framework I can find no .dylibs (same as .so's) in
there. The only thing resembling it is:
[ra@JBravos-Mac-Pro ~]$ file /Library/Frameworks/SDL.framework/Versions/A/SDL
/Library/Frameworks/SDL.framework/Versions/A/SDL: Mach-O universal binary with
2 architectures
/Library/Frameworks/SDL.framework/Versions/A/SDL (for architecture x86_64):
Mach-O 64-bit dynamically linked shared library x86_64
/Library/Frameworks/SDL.framework/Versions/A/SDL (for architecture i386):
Mach-O dynamically linked shared library i386
No PPC version either. Not sure how many PPC's are still out there but I see
no reason not to support them.
The SDL library that is included with the source is looks a bit more pretty:
[ra@JBravos-Mac-Pro ~]$ file ioquake3/code/libs/macosx/libSDL-1.2.0.dylib
ioquake3/code/libs/macosx/libSDL-1.2.0.dylib: Mach-O universal binary with 3
architectures
ioquake3/code/libs/macosx/libSDL-1.2.0.dylib (for architecture ppc): Mach-O
dynamically linked shared library ppc
ioquake3/code/libs/macosx/libSDL-1.2.0.dylib (for architecture x86_64): Mach-O
64-bit dynamically linked shared library x86_64
ioquake3/code/libs/macosx/libSDL-1.2.0.dylib (for architecture i386): Mach-O
dynamically linked shared library i386
If I understand corrently, the main reason for switching to the Framework from
this dylib is that this dylib wants to live in /usr/local/lib and nowhere else
and can not be used in the same folder as the executable and renderer dylib's
are.
This is quite evident when examining the dylib:
[ra@JBravos-Mac-Pro macosx]$ otool -L libSDL-1.2.0.dylib
libSDL-1.2.0.dylib:
/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0,
current version 12.4.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 15.0.0)
[snip]
This is the very same issue I faced when I was embedding the Framework into the
.app bundle but I found ways to modify the binaries to allow this.
MAN-AT-ARMS built a new version of the .dylib and he changed the searchpath so
it looks like this:
[ra@JBravos-Mac-Pro ~]$ otool -L libSDL-1.2.0.dylib
libSDL-1.2.0.dylib:
@executable_path/libSDL-1.2.0.dylib (compatibility version 12.0.0,
current version 12.4.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 15.0.0)
[snip]
This makes the dylib capable of living in the same folder as the executable.
So I suggest the following. I will revert back from using the Framework to
using the updated dylib and keep the dylib in the same folder as the ioquake3
executable and the renderers. If this works reliably on all 3 arches I'll
commit these changes after they have been properly tested.
If we dont like using another build of the SDL dylib, then I can fix the one we
currently ship using a tool that is on the mac. (see the install_name_tool
usage in the make-macosx-ub.sh script for info on how this is done.)
--
JBravo
----- Original Message -----
From: "Zachary" <zach...@ioquake.org>
To: "Primary ioquake3 Discussion/Development list" <ioquake3@lists.ioquake.org>
Sent: Thursday, 27 December, 2012 8:37:32 PM
Subject: [ioquake3] Can somebody try ioquake3 (head) 32bit on an nvidia mac?
You'll need to do +set sv_pure 0 +set vm_cgame 0 +set vm_game 0 +set vm_ui 0
after manually inserting the dylibs and 386 binary into
./ioquake3.app/Contents/MacOS/ioquake3.i386
There is a report of a graphical corruption issue that I can't reproduce, but
I'm on an ati/amd graphics macbook.
_______________________________________________
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.
_______________________________________________
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.
_______________________________________________
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.
