Hi,
Just a quick note, the previous version SVN i386 which built correctly on
my x86_64 10.7.5 machine now exhibits this behaviour:
wayreth:release-darwin-i386 raistlin$ ./ioquake3.i386 +set sv_pure 0 +set
vm_cgame 0 +set vm_game 0 +set vm_ui 0
dyld: Library not loaded: @executable_path/libSDL-1.2.0.dylib
Referenced from:
/Users/raistlin/code/ioquake3/trunk/build/release-darwin-i386/./ioquake3.i386
Reason: image not found
Trace/BPT trap: 5
make-macosx.sh will only produce x86_64 executables on my machine, that's
why I'm using 'make' to build the 32bit version..
Regards,
Vincent
On Mon, 31 Dec 2012, Richard Allen wrote:
I've completed the changes I mentioned in my previous message in this thread.
It's been tested on all three platforms (i386, x86_64 and ppc). All work fine
without using the SDL framework (either installed on the system or embedded in
the .app).
The patch should apply to the current svn version and the dylib needs to be in
code/libs/maxosx/ before the binaries are built.
Oh, and this diff also brings back ppc.
Only issue of note here is that rend2 seems to not do so well on any macosx
platform.
The patch: http://www.ra.is/macfixes.diff
New SDL dylib: http://www.ra.is/macosx-libSDL.tar.gz
----- Original Message -----
From: "Vincent S. Cojot" <vinc...@cojot.name>
To: "Primary ioquake3 Discussion/Development list" <ioquake3@lists.ioquake.org>
Sent: Monday, 31 December, 2012 12:06:09 AM
Subject: Re: [ioquake3] Can somebody try ioquake3 (head) 32bit on an nvidia mac?
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.
_______________________________________________
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.
--
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
Vincent S. Cojot, Computer Engineering. STEP project. _.,-*~'`^`'~*-,._.,-*~
Ecole Polytechnique de Montreal, Comite Micro-Informatique. _.,-*~'`^`'~*-,.
Linux Xview/OpenLook resources page _.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'
http://step.polymtl.ca/~coyote _.,-*~'`^`'~*-,._ coy...@nospam4cojot.name
They cannot scare me with their empty spaces
Between stars - on stars where no human race is
I have it in me so much nearer home
To scare myself with my own desert places. - Robert Frost
_______________________________________________
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.
