OS X compilation issue

[chief1983]

Looks like we may need to only use the c++11 standard definition with .cpp files? I tried with an older minimum Mac OS X version but it still uses the most recent framework available so not much else I can do I don't think. Are we currently applying CXXFLAGS to CFLAGS, or the equivalent, with this CMake setup?

CompileC build/src/PCS2.build/Release/pcs2.build/Objects-normal/x86_64/GLee.o src/GLee.c normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/cliffgordon/scp/PCS2
    export LANG=en_US.US-ASCII
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -arch x86_64 -fmessage-length=256 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -fcolor-diagnostics -Wno-trigraphs -fpascal-strings -O3 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DCMAKE_INTDIR=\"Release\" -DILUT_USE_OPENGL -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ -DUNIX -DHAVE_SYS_TYPES_H -DHAVE_SYS_STAT_H -DHAVE_UNISTD_H -DUSE_SDL -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.9 -Wno-sign-conversion -Wno-infinite-recursion -I/Users/cliffgordon/scp/PCS2/build/src/Release/include -I/Users/cliffgordon/scp/PCS2/src/pugixml -I/Users/cliffgordon/scp/PCS2/src/../res -I/usr/local/include -I/usr/local/include/IL -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 -I/usr/local/include/wx-3.0 -I/Users/cliffgordon/Library/Frameworks/SDL.framework/Headers -I/Users/cliffgordon/scp/PCS2/src/fmt -I/Users/cliffgordon/scp/PCS2/build/src/PCS2.build/Release/pcs2.build/DerivedSources/x86_64 -I/Users/cliffgordon/scp/PCS2/build/src/PCS2.build/Release/pcs2.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/cliffgordon/scp/PCS2/build/src/Release -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks -F/Users/cliffgordon/Library/Frameworks -DNDEBUG -fPIE -I/usr/local/include/wx-3.0 -std=c++11 -MMD -MT dependencies -MF /Users/cliffgordon/scp/PCS2/build/src/PCS2.build/Release/pcs2.build/Objects-normal/x86_64/GLee.d --serialize-diagnostics /Users/cliffgordon/scp/PCS2/build/src/PCS2.build/Release/pcs2.build/Objects-normal/x86_64/GLee.dia -c /Users/cliffgordon/scp/PCS2/src/GLee.c -o /Users/cliffgordon/scp/PCS2/build/src/PCS2.build/Release/pcs2.build/Objects-normal/x86_64/GLee.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

[niffiwan]

the cmake setup is probably incorrect, and there's 3rd party files just chucked in with the PCS2 code. i.e. GLee is 3rd party & should be moved to src/glee.

Or maybe it should be changed to be more like fso; and move all 3rd party stuff into ../lib/DIR (including fmt, pugixml & Glee)

[niffiwan]

Maybe @asarium can offer some suggestions on fixing the cmake config?

[chief1983]

Yeah if that's the way to get per-project compilation options it probably needs to be done. I think older compilers were more lax about this, older LLVM apparently treated it as a warning. Now it's a halting error.

[niffiwan]

ah yes, g++ on 'buntu 16.04 is still treating it as a warning so I didn't worry too much about it before...

[countbuggula]

Benklop's got a fix for it - we're just testing it and if we can get it to work he'll submit the fix.

[asarium]

C++11 is supposed to be handled by the CMake function target_compile_features. Apparently that is currently not used by the PCS2 CMake setup.

[niffiwan]

@countbuggula any news on the fix being tested by Benklop?

[chief1983]

Since FreeBSD is using a new clang version as well, this is also blocking PCS2 from compiling there. Any word on a solution to getting our third party libs from using the same defines as our C++ code?

[chief1983]

@countbuggula ping :)

[chief1983]

Bueller?

[countbuggula]

Well, I changed jobs and no longer have Mac so I need to check with benklop and see what he has. Thanks for the reminder.

…

On Sat, Jun 3, 2017, 9:47 AM Cliff Gordon ***@***.***> wrote: Bueller? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjTNmMTpBK7XojNBMHewse78eWsUFnvks5sAYAPgaJpZM4LF_TU> .

[chief1983]

After looking into this, it actually seemed to have come from fmt's own CMake config file. fmt avoids setting the CPP11_FLAG argument if a CXX standard is defined within CMake already, so I tested defining one on the command line and that caused this error to stop. A solution therefore might be to permanently define the C++11 standard within our main CMake files and the fmt one should avoid setting it in a way that conflicts with C files.

[Goober5000]

A solution therefore might be to permanently define the C++11 standard within our main CMake files

I think this has been done. Can this be closed?

[chief1983]

I haven't tried compiling PCS2 in ages so I can't confirm or deny this is still an issue. I can try it again on my Macbook and see if something similar is still happening. But if we see an actual change has been made to the repo to account for this since it was filed, then we can go ahead and close it out and I'll file a new or reopen this if I run into any issues next time I try compiling it.

[Goober5000]

I don't actually know for sure whether the change has been made. I thought it had been, but I don't have a Mac to check.