Lion compile failure

[Joshua Root]

On 2012-6-15 06:14 , Craig Treleaven wrote:
> Hi:
> 
> 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
> thought I'd be able to get around the problem by installing port
> apple-gcc42 and using that to build my project:
> 
> sudo port -dn install configure.compiler=apple-gcc-4.2
> configure.cxx=g++-apple-4.2
> ...
>> gcc -c -pipe -I/opt/local/include -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
>> -Wundef -Wmissing-prototypes -O3 -fno-math-errno -fno-tree-vectorize
>> -w -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.7 -DMMX
>> -DUSING_APPLEREMOTE -D_GNU_SOURCE
>> -I/opt/local/share/qt4/mkspecs/macx-g++ -I. -I/usr/include
>> -I/opt/local -I/opt/local/include/libxml2 -Ireplex
>> -I../../../external/FFmpeg -I../../../libs/libmythbase -o ts.o ts.c
>> {standard input}:465:can't encode register '%ah' in an instruction
>> requiring REX prefix.
>> make[2]: *** [ts.o] Error 1
>> make[2]: Leaving directory
>> `/opt/local/var/macports/build/_Users_ctreleaven_MacPortsTemp_mythtv-core.25/mythtv-core.25/work/mythtv-9ccfac11f3/mythtv/programs/mythtranscode/replex'
>>
>> make[1]: *** [sub-mythtranscode-replex-make_default] Error 2
>> make[1]: *** Waiting for unfinished jobs....
> 
> I've compared a working build on 10.6 with the failed build on 10.7 and
> the ONLY difference in the arguments is "-mmacosx-version-min=10.7" on
> Lion.
> 
> I also don't understand why the error message says "{standard
> input}:465:" rather than referencing the souce file "ts.c"?
> 
> Any clues or thoughts?

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.)

- Josh