Build for x265 32-bit shared library fails on Mac 10.6

[Terri]

Summary of the bug:

I am trying to build 32-bit shared library on Mac 10.6.
And the build fails.

I've used:

- The latest revision of x265, multicoreware-x265-e6ba953dcb1a, 2014-05-28
- CMake 2.8.12.2
- CMAKE_OSX_ARCHITECTURES=i386
- ENABLED_SHARED

Error message:

Scanning dependencies of target x265-shared
Linking CXX shared library libx265.dylib
ld: warning: in common/CMakeFiles/common.dir/x86/pixel-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/const-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/cpu-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/ssd-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/mc-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/mc-a2.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/pixel-util8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/blockcopy8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/pixeladd8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/dct8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/sad-a.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/intrapred8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/ipfilter8.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in common/CMakeFiles/common.dir/x86/loopfilter.asm.o, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
  "_x265_pixel_ssd_64x16_sse4", referenced from:
      _x265_pixel_ssd_64x16_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_pixel_ssd_64x16_sse4$non_lazy_ptr)
  "_x265_intra_pred_ang32_26_sse4", referenced from:
      _x265_intra_pred_ang32_26_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_intra_pred_ang32_26_sse4$non_lazy_ptr)
  "_x265_intra_pred_ang32_31_sse4", referenced from:
      _x265_intra_pred_ang32_31_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_intra_pred_ang32_31_sse4$non_lazy_ptr)
  "_x265_blockcopy_ps_2x8_sse4", referenced from:
      _x265_blockcopy_ps_2x8_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_blockcopy_ps_2x8_sse4$non_lazy_ptr)
  "_x265_interp_4tap_horiz_pp_24x32_sse4", referenced from:
      _x265_interp_4tap_horiz_pp_24x32_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_interp_4tap_horiz_pp_24x32_sse4$non_lazy_ptr)
  "_x265_interp_4tap_vert_pp_8x6_sse4", referenced from:
      _x265_interp_4tap_vert_pp_8x6_sse4$non_lazy_ptr in asm-primitives.cpp.o
     (maybe you meant: _x265_interp_4tap_vert_pp_8x6_sse4$non_lazy_ptr)
   …
   …

The reason it fails:
i386 build generates the function names without leading underscore, "_", and the linker looks for functions with a leading underscore, and this makes the i386 build fail.

[Carl Eugen Hoyos]

Is there a problem with the FFmpeg codebase or did you report this on the wrong bug tracker?

[Carl Eugen Hoyos]

Please reopen this ticket if there is a problem that can be fixed within FFmpeg.