ffmpeg: +universal variant

[daitakahashi]

Missing universal variant of ffmpeg prevents universal build of dependent ports (e.g., gimp2 depends on gegl). To solve this problem, I attached a patch that enables +universal variant of ffmpeg. I tested only a case when universal_archs is i386 x86_64, however, I think this patch will work for other architecture combinations.

[fran6co@…]

It's not working for me:

:info:build /usr/bin/gcc-4.2 -I. -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/ffmpeg-0.6.1-i386" -I/opt/local/include -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -pipe -O2 -DHAVE_LRINTF -I/opt/local/include -arch i386   -std=c99 -fomit-frame-pointer -fPIC -I/opt/local/include/dirac -I/opt/local/include/schroedinger-1.0 -I/opt/local/include/orc-0.4 -g -Wdeclaration-after-statement -Wall -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 -Werror=implicit -Werror=missing-prototypes          -MMD -MF libavcodec/h264_cavlc.d -MT libavcodec/h264_cavlc.o -c -o libavcodec/h264_cavlc.o libavcodec/h264_cavlc.c
:info:build libavcodec/h264_cavlc.c: In function 'decode_residual':
:info:build libavcodec/h264_cavlc.c:411: warning: suggest parentheses around comparison in operand of &
:info:build libavcodec/cabac.h: In function 'get_cabac_noinline':
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h: In function 'decode_cabac_mb_ref':
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h: In function 'decode_cabac_residual_nondc':
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/x86/h264_i386.h:97: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/x86/h264_i386.h:44: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h: In function 'decode_cabac_residual_dc':
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/x86/h264_i386.h:97: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/x86/h264_i386.h:44: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h: In function 'decode_cabac_mb_mvd':
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:527: error: PIC register '%ebx' clobbered in 'asm'
:info:build libavcodec/cabac.h:641: error: PIC register '%ebx' clobbered in 'asm'
:info:build gmake: *** [libavcodec/h264_cabac.o] Error 1
:info:build gmake: *** Waiting for unfinished jobs....

[fran6co@…]

I think the problem is when compiling something in 32bits when using a 64bit system.

[daitakahashi]

Could you post the whole build-log? I would like to see ./configure arguments.

[fran6co@…]

Full log

[fran6co@…]

Cc Me!

[daitakahashi]

Workaround at platform darwine 10 was needed to adapt universal variant. Updated patch will solve the problem.

[daitakahashi]

Update platform darwin 10

[fran6co@…]

That way it disables mmx from the 32bit build. The compilation error seems to be a know issue with gcc when doing cross compilation with assembly code. Not sure if disabling mmx is the correct patch.

[daitakahashi]

Your problem may come from the ignorance of target arch at the usability check of ebx resister. The new patch will solve a clobbering problem (mmx workaround is disabled to confirm that this is a separate problem).

[daitakahashi]

add ASFLAGS to configure environment

[fran6co@…]

Different log with the last patch, but it's weird because it's not stopping at the first error found.

[daitakahashi]

Thank you for testing. Your log shows the first error (libavcodec/h264_cavlc.c compilation) is fixed, so the second problem is a different one (may relate to #20938). In my environment (OSX 10.5.8 Core2Duo), not gcc-4.0 but gcc-4.2 reproduced similar problem.

/usr/bin/gcc-4.2 -I. -I"/opt/local/var/macports/build/_LocalPort_port_multimedia_ffmpeg/work/ffmpeg-0.6.1" -I/opt/local/include -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -pipe -O2 -DHAVE_LRINTF -I/opt/local/include -arch i386   -std=c99 -fomit-frame-pointer -fPIC -I/opt/local/include/dirac -I/opt/local/include/schroedinger-1.0 -I/opt/local/include/orc-0.4 -g -Wdeclaration-after-statement -Wall -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          -MMD -MF libavcodec/x86/dsputil_mmx.d -MT libavcodec/x86/dsputil_mmx.o -c -o libavcodec/x86/dsputil_mmx.o libavcodec/x86/dsputil_mmx.c
/dsputil_mmx.clibavcodec/x86/h264dsp_mmx.c: In function `h264_h_loop_filter_luma_mmx2':
libavcodec/x86/dsputil_mmx.c:727: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
libavcodec/x86/dsputil_mmx.c:727: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
libavcodec/x86/dsputil_mmx.c:727: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
libavcodec/x86/dsputil_mmx.c:727: error: `asm' operand has impossible constraints
... long error messages

The problem was avoided by the suppression of inlining (-fno-inline or -finline-limit=small integer, possibly generates slow binary). I hope this can be applicable for 10.6 environment. The updated portfile includes this fix.

[daitakahashi]

disable inlining for intel 32bit architecture (darwin 10)

[daitakahashi]

I also think that the patch posted on ​https://roundup.ffmpeg.org/issue2088 can be helpful.

[fran6co@…]

I'm testing your patch because I'm trying to build opencv as a universal binary and ffmpeg is a strong dependency.

With the -fno-inline change it managed to compile, didn't try it if it works.

It also works using the patch to dsputil_mmx.c. I like that solution better because it doesn't disable inlining for 386 build. I think it needs to be tested on a 32bit environment, because this could be a fix for ticket #20938.

[fran6co@…]

The Portfile that worked for me

[fran6co@…]

And the patch

[fran6co@…]

If this portfile gets accepted in Macports it should have a comment explaining that this is a gcc bug, not of ffmpeg.

[daitakahashi]

Your updated patch works without any problems (OSX 10.5, i386/x86_64 universal), thank you very much.

For future reference: the link I posted here has been 404 since this morning, but the message can be found at ​mail-archive.

[n.a.hawes@…]

Cc Me!

[daitakahashi]

Changes discussed here seems to be safely applicable for updated (0.6.2) ffmpeg port (snow leopard 64bit host, i386/x86_64). Could someone test updated port (with above changes) if it works?

[fran6co@…]

Works for me! (Snow Leopard 10.6.7 64bit)

[dbevans (David B. Evans)]

I have applied this most recent set of patches and have confirmed that it builds properly in the following cases:

Snow Leopard 10.6.7 x86_64 both universal and not Leopard 10.5.8 ppc not universal (universal is still building)

I've lost track of who's tested what where. If someone can verify that it works on i386 platforms (both Snow Leopard and Leopard would be good) then I'm ready to commit these changes.

[daitakahashi]

No problem was found on leopard machine (32bit Core2 Duo, for both i386 and i386/x86_64 universal).

[daitakahashi]

I confirmed that the newest ffmpeg 0.6.3 built fine with above patches (Snow leopard 10.6.7, Macbook Pro early 2011, i386/x86_64 universal).

[neverpanic (Clemens Lang)]

Cc Me!

[daitakahashi]

proposed patch (updated for ffmpeg 0.6.3_1)

[daitakahashi]

Although a small change is needed to adapt ffmpeg-0.6.3_1 (above patch), patches uploaded on this thread work fine with current ffmpeg port (Snow leopard 10.6.7, Macbook Pro early 2011, i386/x86_64 universal).

[ryandesign (Ryan Carsten Schmidt)]

This ticket is long and I haven't read everything in it. Is this patch still needed for ffmpeg @0.7.1? What about ffmpeg-devel @20110628? If so, do the patches need to be refreshed for those versions, and if so, can someone do that?

[daitakahashi]

As far as I tested, ffmpeg @0.7.1 does not require any of those patches (x86_64 and i386/x86_64 universal, OS X 10.6.8). I attach the patch to Portfile below.

[mroman@…]

@dtakahashi42 Your path compiled ok in 32-bit 10.6 with gcc 4.5. Thanks!

[ryandesign (Ryan Carsten Schmidt)]

I committed a version of this latest patch in r82651. It allowed me to build ffmpeg for x86_64, i386, and both (universal), on Snow Leopard with Xcode 3.2.6, where before I was only able to build for x86_64. Hopefully this works on other configurations as well.