Talk:Compiling in Mac OS X

From OHRRPGCE-Wiki
Jump to navigation Jump to search

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.