Lion compile failure

[Craig Treleaven]

At 8:20 PM -0700 6/14/12, Jeremy Huddleston wrote:
>On Jun 14, 2012, at 7:33 PM, Craig Treleaven <ctreleaven at cogeco.ca> wrote:
>
>>  At 6:28 AM +1000 6/15/12, Joshua Root wrote:
>>>  On 2012-6-15 06:14 , Craig Treleaven wrote:
>>>  > The port I've been working on (endlessly, it seems) compiles fine on
>>>  > 10.6 but fails on 10.7.  After a few runs trying both clang and llvm, I
>>>  > [...]
>>>
>>>  Well first of all it's running 'gcc', not obeying ${configure.cc} and
>>>  friends. You should fix that. So it's currently using llvm-gcc-4.2 on
>>>  Lion no matter what.
>>>
>>>  Secondly, the inline asm may well be incorrect. (The "standard input" is
>>>  probably because the message is coming from the assembler, which is
>>>  being called by the compiler on the snippet of asm, not the C file.)
>>>
>>
>>  Thanks for the pointers (here and offline). I got a successful 
>>build using macports-gcc42.  I've incorporated the block to use 
>>macports-gcc42 as necessary viz:
>
>Do you mean apple-gcc-4.2?  macports-gcc-4.2 is *very* old and AFAIK 
>only compiles on Tiger.  gcc43 and later should work on Leopard and 
>newer.  apple-gcc42 should work on Tiger and newer.

Yes, apple-gcc-4.2.  Thanks for clarifying...I've been a bit puzzled 
about the differences of the various [blah]-gcc-42's.


>  > https://trac.macports.org/wiki/PortfileRecipes#compiler
>>
>>
>>  If anybody is interest, using llvm fails as in my original posting:
>
>Nobody's really interested in llvm-gcc at this point in time.  If it 
>doesn't work, try with clang and dragonegg.  llvm-gcc is pretty much 
>dead.
>
>>  ...
>>  Failure with clang comes earlier, ala:
>>
>  >> /usr/bin/clang -c -pipe -pipe -D_ISOC99_SOURCE 
>-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_DARWIN_C_SOURCE -DPIC 
>-pipe -O2 -arch x86_64 -std=c99 -fomit-frame-pointer -fPIC -g -Wall 
>-Wno-parentheses -Wno-switch -Wdisabled-optimization -Wpointer-arith 
>-Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings 
>-Wtype-limits -Wundef -Wmissing-prototypes -O3 -fno-math-errno 
>-fno-signed-zeros -Qunused-arguments -O2 -arch x86_64 -Xarch_x86_64 
>-mmacosx-version-min=10.7 -DMMX -DUSING_APPLEREMOTE -D_GNU_SOURCE 
>-DUSE_LIRC -DUSE_OPENGL_PAINTER -DUSING_QTWEBKIT -DMUI_API 
>-DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SQL_LIB -DQT_XML_LIB 
>-DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB 
>-DQT_SHARED -I/opt/local/share/qt4/mkspecs/macx-g++ -I. -I. 
>-I/usr/include -I/opt/local -I/opt/local/include/libxml2 
>-I../libmythbase -I../.. -I.. -I../../external/FFmpeg 
>-I/opt/local/include/QtWebKit -I/opt/local/include/QtSql 
>-I/opt/local/include/QtXml -I/opt/local/include/QtOpenGL 
>-I/opt/local/include/QtGui -I/opt/local/include/QtNetwork 
>-I/opt/local/include/QtCore -I/opt/local/include 
>-I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers 
>-I/System/Library/Frameworks/AGL.framework/Headers util-osx-cocoa.mm 
>-o util-osx-cocoa.o
>>>  error: invalid argument '-std=c99' not allowed with 'C++/ObjC++'
>>>  make[2]: *** [util-osx-cocoa.o] Error 1
>
>That's a bug in myth's build system.  They're compiling ObjC++ code 
>(util-osx-cocoa.mm) with -std=c99, which is not valid.  You should 
>either fix it or report the bug to myth developers to fix.  That 
>issue is probably ignored by gcc.

Understood; when I get some time, I'll try to come back to this.  A 
quick search suggests this is the one and only '*.mm' file in the 
entire code base.  I suppose it is a case of adding an exception for 
it...somewhere.  Right now, I need to test with Michael's newly 
released qt4-mac @4.8.2, update to a more recent MythTV commit, fix 
some more hard-coded prefixes, write some docs, ...

Craig