Talk:Compiling in Mac OS X
Bob the Hamster (talk) 10:23, 8 September 2016 (PDT): I am unable to compile on Mac OS X 10.11
Trying to compile with the fbc-1.06 port linked from this article fails like this: http://pastebin.com/raw/CTEWiacJ
Trying to compile with the fbc 0.22 port that worked on my old 10.6 mac fails like this: http://pastebin.com/raw/WM0GPFjn
Using the workaround to force gcc instead of clang does not appear to help, failing like this: http://pastebin.com/raw/ZywCrgXq
Fortunately I can keep my old Mac plugged in for now, so nightly Mac builds are not broken yet
TMC (talk) 03:17, 9 September 2016 (PDT): You are going to have to use gcc rather than clang to compile, as you tried. Actually, could you try compiling with "scons debug=0" to disable -exx (which is to blame to for those 'indirect goto' errors) (with FB 1.06 and without providing GCC/CC envvars).
In recent OSX 'gcc' is actually clang, and I guess ideally scons would check that, but I'm not sure how it reports itself, so could you please report the output of the following (with builtin gcc, not /opt/local/bin/gcc):
gcc --version clang --version gcc -dumpversion clang -dumpversion
The error when compiling os_unix.c seems to be due to using C++11 attributes in C code; I get the same error here (turns out I was testing for the wrong compiler version, but gcc and clang recently added handy macros like __has_feature, __has_attribute, __has_extension that ought to be used instead of testing for compiler versions). Fixed.
As for the error on '-mpreferred-stack-boundary=2' (only supported by gcc), I was about remove that anyway as it's no longer needed, but that doesn't help because it affects FB 0.22 only.
Bob the Hamster (talk) 07:43, 9 September 2016 (PDT):
Here is the output of the build-in gcc an clang: http://pastebin.com/raw/R0A9u5Hj it looks like gcc --version does conveniently identify itself as clang
I then realized that /opt/local/bin/gcc does not actually exist on my system, even though I definitely had already installed gcc from macports and already used it to compile some non-ohrrpgce-related stuff. I realized that what I had been using was one of these:
palsink:~/src/ohr/wip james$ ls -l /opt/local/bin/gcc* -rwxr-xr-x 2 root admin 36960 Jan 30 2016 /opt/local/bin/gcc-ar-mp-4.7 -rwxr-xr-x 2 root admin 43240 Jun 9 23:46 /opt/local/bin/gcc-ar-mp-5 -rwxr-xr-x 3 root admin 774396 Jan 30 2016 /opt/local/bin/gcc-mp-4.7 -rwxr-xr-x 3 root admin 1131416 Jun 9 23:46 /opt/local/bin/gcc-mp-5 -rwxr-xr-x 2 root admin 36960 Jan 30 2016 /opt/local/bin/gcc-nm-mp-4.7 -rwxr-xr-x 2 root admin 43320 Jun 9 23:46 /opt/local/bin/gcc-nm-mp-5 -rwxr-xr-x 2 root admin 36968 Jan 30 2016 /opt/local/bin/gcc-ranlib-mp-4.7 -rwxr-xr-x 2 root admin 43328 Jun 9 23:46 /opt/local/bin/gcc-ranlib-mp-5
With fbc-1.06 I tried CC=clang GCC=/opt/local/bin/gcc-mp-5 scons debug=0 but it failed like this: http://pastebin.com/raw/Gi36XYig
TMC (talk) 05:17, 10 September 2016 (PDT): Thanks. Apparently the clang in xcode uses a different version numbering system than regular clang (it reports the xcode version?), and doesn't even print the clang version in the -version info! That -dumpversion string looks like the real version number.
You didn't compile the latest svn revision with my fix.
You don't need to pass debug=0, that was only a suggested workaround for getting it to compile with clang instead of gcc.
Bob the Hamster (talk) 09:30, 12 September 2016 (PDT): Success! Thank you! :)
I saw a few unfamiliar warnings, but apparently nothing that prevents the binary from working great. http://pastebin.com/raw/vd1aZeuz
Bob the Hamster (talk) 10:43, 12 September 2016 (PDT): Oh, I should also mention that I manually copied over my /Developer/SDK folder from the old mac nightly build box to the new one, since I couldn't find any other way to get the OS X 10.4 SDK
Bob the Hamster (talk) 12:27, 12 September 2016 (PDT): Actually, calling distrib-nightly-mac.sh with the macsdk=10.4 argument doesn't work for me, so I don't think copying over the SDK files actually did anything.
I can compile Mac nightlyies, but I have absolutely no idea what the minimum OS X version supported is.
I should mention I haven't seen a working mac with 10.5 or older in years, and the whole reason I had to replace my 10.6 box is because the compatibility was declining and I couldn't do things I needed to do with it anymore :(
TMC (talk) 22:08, 12 September 2016 (PDT): I actually think that it is not necessary to compile against the SDK, but that it is the most sure way to produce a binary that will run on 10.4. Whereas if you use -mmacosx-version-min=10.4 you can still call APIs that don't exist on 10.4 and it won't run [1]. However, I think (I'm starting to forget he details) that the build of FB 1.06 I provided for OSX actually can't produce 10.4-compatible binaries, because when I tried to use the macsdk=10.4 option I got an error, probably the same one you saw. I have been meaning to recompile FB to try to fix it. I hope the fixed build will be 10.4 compatible without even needing the SDK, but linking against the 10.4 libraries in the SDK provides a good test of compatibility. In the meantime, I suggest just not passing macsdk=10.4 to scons when compiling mac nightlies. It ought to work on 10.6+.
Also, the warning about [NSApp setDelegate:sdlMain] is odd, I should look into that. The warnings in sourceslices.bi are normal warnings when using -gen gcc, because the generated functions are so large that they exceed gcc limits.