At 8:20 PM -0700 6/14/12, Jeremy Huddleston wrote:
On Jun 14, 2012, at 7:33 PM, Craig Treleaven <ctrelea...@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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
