MPlayer @1.1_3: fails to build for powepc

[reeskm (Rees Machtemes)]

Will not build. Seems to be problems with inline functions in main.log

[reeskm (Rees Machtemes)]

main.log

[reeskm (Rees Machtemes)]

Modded portfile that seems to fix this bug!

[reeskm (Rees Machtemes)]

Seems like you can't build this with apple-gcc-4.0 that is my default compiler on 10.5.8.

modded the portfile to force gcc suite to be apple-gcc-4.2 and it built and installed.

maybe blacklist the old compiler? how does this affect the build on 10.4? Let me know if you need it to be regression tested since I have some old xserve g4's kicking around with osx-server 10.4

[larryv (Lawrence Velázquez)]

portfile diff

[larryv (Lawrence Velázquez)]

If you just want to prevent the use of GCC 4.0, you’ll probably want to go with

compiler.blacklist gcc-4.0 apple-gcc-4.0

to allow use of other compilers.

[jeremyhu (Jeremy Huddleston Sequoia)]

gcc-4.0 was already blacklisted, but I added apple-gcc-4.0 in r103116 ... please remember to port sync before filing a bug to see if it's still relevant.

[reeskm (Rees Machtemes)]

Failed again with the new port and blacklist. This time it used llvm-gcc-4.2. Logfile attached.

[reeskm (Rees Machtemes)]

Fails to compile with llvm-gcc-4.2 (log)

[jeremyhu (Jeremy Huddleston Sequoia)]

libavcodec/ffv1.c:296: sorry, unimplemented: inlining failed in call to 'put_symbol_inline': function not considered for inlining
libavcodec/ffv1.c:496: sorry, unimplemented: called from here
libavcodec/ffv1.c:296: sorry, unimplemented: inlining failed in call to 'put_symbol_inline': function not considered for inlining
libavcodec/ffv1.c:498: sorry, unimplemented: called from here
libavcodec/ffv1.c:296: sorry, unimplemented: inlining failed in call to 'put_symbol_inline': function not considered for inlining
libavcodec/ffv1.c:496: sorry, unimplemented: called from here
libavcodec/ffv1.c:296: sorry, unimplemented: inlining failed in call to 'put_symbol_inline': function not considered for inlining
libavcodec/ffv1.c:498: sorry, unimplemented: called from here

[patrick@…]

Cc Me!

[patrick@…]

Cc Me!

[prynhart@…]

Cc Me!

[prynhart@…]

Replying to prynhart@…:

Cc Me!

Adding myself as I'm affected by this issue (attempting to compile using llvm-gcc-4.2).

[sasoph@…]

Cc Me!

[udbraumann]

Cc Me!

[udbraumann]

Building MPlayer with apple-gcc-4.2 has worked in my case:

sudo port upgrade MPlayer configure.compiler=apple-gcc-4.2

So I recommend to set this compiler at the portfile level.

PS: please do not forget to do a cleaning before doing this upgrade after it has failed with llvm-gcc-4.2

sudo port clean MPlayer

[prynhart@…]

I can confirm that the suggestion of braumann works for me on PPC (10.5.8), so specifying this compiler at the portfile level may be possible way forward. P.S.: Thanks braumann :)

[reeskm (Rees Machtemes)]

I've rebuilt Mplayer also on 10.4 and reached the same conclusion - llvm 4.2 and gcc 4.0 are not enough to compile Mplayer 1.1_3.

I also agree with braumann that requiring this compiler (or apple-gcc above 4.2) should be done.

[sasoph@…]

mplayer-devel @36126_0 on 10.5.8 PPC has also been built successfully using apple-gcc-4.2.

[prynhart@…]

Very good. (And just when I thought I was just about the only one in the world attempting to build mplayer on OSX PPC.)

[ryandesign (Ryan Carsten Schmidt)]

On 10.5 i386, MPlayer also fails to build for me with either llvm-gcc-4.2:

libmpcodecs/vf_filmdint.c:1461: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
{standard input}:0:End-of-File not at end of a line
{standard input}:428:End-of-File not at end of a line
{standard input}:unknown:Partial line at end of file ignored
{standard input}:unknown:Undefined local symbol L_calloc$stub
{standard input}:unknown:Undefined local symbol L_gCpuCaps$non_lazy_ptr
{standard input}:unknown:Undefined local symbol L_strchr$stub
{standard input}:unknown:Undefined local symbol LC
{standard input}:unknown:Undefined local symbol L_sscanf$stub
{standard input}:unknown:Undefined local symbol LC1
{standard input}:unknown:Undefined local symbol LC2
{standard input}:unknown:Undefined local symbol LC3
{standard input}:unknown:Undefined local symbol LC4
{standard input}:unknown:Undefined local symbol LC5
{standard input}:unknown:Undefined local symbol LC6
{standard input}:unknown:Undefined local symbol LC7
{standard input}:unknown:Undefined local symbol LC8
{standard input}:unknown:Undefined local symbol LC9
{standard input}:unknown:Undefined local symbol LC11
{standard input}:unknown:Undefined local symbol L_mp_msg$stub
{standard input}:unknown:Undefined local symbol LC10
{standard input}:unknown:Undefined local symbol LBB2_23
{standard input}:unknown:Undefined local symbol L_fast_memcpy$stub

or macports-llvm-gcc-4.2:

Undefined symbols for architecture i386:
  "_MM_FIX_0_707106781", referenced from:
      _filter in vf_fspp.o
  "_MM_FIX_0_541196100", referenced from:
      _filter in vf_fspp.o

These compilers should be blacklisted.

It succeeds with gcc-4.0 build 5493 and gcc-4.2 build 5577, both of which are blacklisted by the port, and perhaps shouldn't be?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

It succeeds with gcc-4.0 build 5493 and gcc-4.2 build 5577, both of which are blacklisted by the port, and perhaps shouldn't be?

r92107 and r95682

Perhaps the issue building cpudetect.c that prompted the blacklisting of gcc-4.0 and older gcc-4.2 has been resolved.

[jeremyhu (Jeremy Huddleston Sequoia)]

r105592

[cooljeanius (Eric Gallager)]

Cc Me!