Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: Tinman on December 04, 2009, 02:22:32 pm
-
SVN 5694 commit breaks MacOSX compiling - please look into it :)
-
Fixed in 5698.
Next time, please include some more information than 'it's borked'!
Issue was that disableWindowsKey was moved from within WinMain (protected by _WIN32 ifdef) into game_main (not protected by _WIN32 ifdef)
-
Next time, please include some more information than 'it's borked'!
I'll do.
But as the 5694 commit was only the Windowskey-thing I thought that was clear :)
Thanks for the fast response!
-
Yeah I'll admit, that was even my hunch just after looking at the diff :)
-
Not the best thread to mention it: but the MacOS X building process is broken again. :p
As far as I can see it is SVN5715 (with a lot of errors)
One of the MacOS X developers may have to look into this :)
-
Nope. Update to 5716. Portej forgot to sync the new gropenglpostprocessing.cpp anh .h files when he merged Antipodes into Trunk.
-
Yes. I used SVN5716 to build fs2Open (and added the files of 5716 manually to the XCode project) but it throws 24+ errors
(I tested SVN5713: build process ok)
-
Hmm. Hery's original commit of postprocessing to Antipodes included xcode updates, as did portej's port of it to Trunk. See the patch in my latest Test Build for confirmation.
What are the errors that it throws? And can you revert or checkout a 5713 and apply the postprocessing.patch from my Test Build post and see if it does the same behaviour?
-
Zacam: I probably screwed something up - I've got no way of testing Xcode files
(sorry about forgetting gropenglpostprocessing.cpp/h - fixed now though!)
-
****. It seems my .patch nor Hery's original .patch included xcode data. Frak.
-
I also noticed that commit 5715/5716 (Antipodes #4) didn't update the Xcode project file. I've updated my local Xcode project file and am running a test build now.
Results should be available soon - and I can commit my locally change Xcode project file if all is green.
Update: Xcode project file has been updated so that the gropenglpostprocessing.cpp/h files are included. I committed a small fix to address GCC's capitalisation requirements for MIN(). Compile issues still remain at present, further work needed.
-
Sweet. Thank you, Echelon9. I'm pretty sure my notepad hack job in 5718 wasn't going to do it.
FYI, there was a line added to xcode in the merge (4949) that according to chief was removed for a reason. Keep that in mind if you need to and feel free to pluck it back out if you have to.
-
I don't know if it is of any help, but this are some error-messages (after SVN5719)
[attachment deleted by admin]
-
That was obviously my fault. Looks like I confused object types while merging old shaders management code with the shaders manager.
I'm already solving that problem.
-
Hery, I applied the patch you provided to Tinman and myself. Improved, but there are three remaining compile errors on my platform.
../../code/graphics/gropenglshader.cpp:438: error: prototype for 'void opengl::shader::set_uniform(unsigned int, GLint)' does not match any in class 'opengl::shader'
../../code/graphics/gropenglshader.h:163: error: candidates are: void opengl::shader::set_uniform(unsigned int, float)
../../code/graphics/gropenglshader.h:157: error: void opengl::shader::set_uniform(unsigned int, int)
Was Tinman able to compile a clean build?
-
Yes. Compiled without errors. MacOS X 10.6.2 , XCode 3.2.1.
-
Thanks Tinman. My remaining compile issues with Hery's shader code may be platform specific; I'm using Xcode 2.5 on MacOS X 10.4.11 (PPC) while my primary development laptop is in for repairs.
-
This patch solves this problem. Let me know if there is still something else to fix.
[attachment deleted by admin]
-
Compiling works fine on my Mac with latest patch.
Application is also working! :yes:
-
Gah... I am having a frustrating time trying to apply this patch file (last time I had to make the changes manually).
$ patch -p0 -i ../gcc_macosx_fix.patch
(Stripping trailing CRs from patch.)
patching file code/graphics/gropenglshader.cpp
Hunk #1 FAILED at 250.
Hunk #2 FAILED at 313.
Hunk #3 FAILED at 381.
Hunk #4 FAILED at 425.
Hunk #5 FAILED at 475.
5 out of 5 hunks FAILED -- saving rejects to file code/graphics/gropenglshader.cpp.rej
(Stripping trailing CRs from patch.)
patching file code/graphics/gropenglshader.h
Hunk #1 FAILED at 154.
Hunk #2 FAILED at 204.
Hunk #3 FAILED at 214.
Hunk #4 FAILED at 233.
Hunk #5 FAILED at 325.
Hunk #6 FAILED at 334.
Hunk #7 FAILED at 344.
Hunk #8 FAILED at 353.
Hunk #9 FAILED at 383.
9 out of 9 hunks FAILED -- saving rejects to file code/graphics/gropenglshader.h.rej
It's not happening because I am trying to apply this to a working copy at a different revision to the patch, as both are 5726.
$ svn info
Path: .
URL: svn://svn.icculus.org/fs2open/trunk/fs2_open
Repository Root: svn://svn.icculus.org/fs2open
Repository UUID: 387891d4-d844-0410-90c0-e4c51a9137d3
Revision: 5726
Node Kind: directory
Schedule: normal
Last Changed Author: Sushi
Last Changed Rev: 5726
Last Changed Date: 2009-12-19 01:22:01 +0800 (Sat, 19 Dec 2009)
Properties Last Updated: 2009-12-14 17:03:41 +0800 (Mon, 14 Dec 2009)
$ head -n 4 ../gcc_macosx_fix.patch
Index: code/graphics/gropenglshader.cpp
===================================================================
--- code/graphics/gropenglshader.cpp (revision 5726)
+++ code/graphics/gropenglshader.cpp (working copy)
I've Google'd for newline and CRLF issues when using a Windows produced patch on OS X / Unix with no success with any of the suggested fixes, nor with --ignore-whitespaces or -Fn. Any help or suggestions?
-
Gah... I am having a frustrating time trying to apply this patch file (last time I had to make the changes manually).
[...]
I've Google'd for newline and CRLF issues when using a Windows produced patch on OS X / Unix with no success with any of the suggested fixes, nor with --ignore-whitespaces or -Fn. Any help or suggestions?
I ran into the same problems on MacOS X for both patches.
I used my Win7 box with TortoiseSVN to merge the patch and copied both files gr...cpp/.h to my Mac.
(And also compiled it on Win7 VS2008Pro)
edit: files attached, HTH :D
[attachment deleted by admin]
-
Thanks Tinman!
Update: Attached is a .patch file that is of Hery's most recent changes (December 19, 2009, 07:30:58 pm (http://www.hard-light.net/forums/index.php?topic=66848.msg1325633#msg1325633)), in a format that will work on Mac OS X.
[attachment deleted by admin]
-
Committed in r5727 (http://svn.icculus.org/fs2open?view=rev&revision=5727), at Hery's request.
-
MacOS X compiling is broken due to TrackIR ->gTirDll_TrackIR stuff in freespace.c and lua.c and maybe somewhere else?
I think it needs to be in win32 only.
Maybe a SCP Mac developer can look into it. :)
-
Need build log please.
-
Undefined symbols:
"_gTirDll_TrackIR", referenced from:
_gTirDll_TrackIR$non_lazy_ptr in freespace.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Undefined symbols:
"_gTirDll_TrackIR", referenced from:
_gTirDll_TrackIR$non_lazy_ptr in libcode.a(lua.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
HTH
-
I have absolutely no idea if this will help in the slightest, but here is an SVN .patch based off of nothing at all other than logical assumption:
(Apple-Click or Right-Click and Save-As)
http://zacam.ueuo.com/scp/Patches/TrackIR_xcode.patch
-
Revision 5789 build fine with Xcode 3.2.1
-
Yup fixed it last night with commit 5788. Thought there were still some issues, so I updated SVN, reverted the xcodeproj to 5762, before any TrackIR stuff went in, then added and deleted the necessary files in Xcode. It looked pretty clean compared to the 5762 version, so I committed over whatever was currently in SVN. If there were any other xcodeproj changes made, which it did not seem they were, they may have been missed. Pretty sure it was all related to TrackIR fixery though.