Opened 9 years ago

Closed 4 years ago

#48336 closed defect (fixed)

x265 build fails on Leopard G4 PPC

Reported by: zzanderr Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: leopard PowerPC Cc: dbevans (David B. Evans), udbraumann
Port: x265

Description

Build fails with message

cd /mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/build/common && /Developer/usr/bin/g++-4.2   -DHAVE_INT_TYPES_H=1 -DHIGH_BIT_DEPTH=0 -DMACOS -D__STDC_LIMIT_MACROS=1 -pipe -Os -arch ppc  -DNDEBUG -arch ppc -mmacosx-version-min=10.5 -I/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/. -I/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/common -I/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/encoder -I/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/build    -Wall -Wextra -Wshadow -ffast-math -fno-exceptions -o CMakeFiles/common.dir/common.cpp.o -c /mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/common/common.cpp
/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/common/common.cpp: In function ‘void* x265_malloc(size_t)’:
/mp2/local/var/macports/build/_mp2_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_x265/x265/work/x265_1.7/source/common/common.cpp:79: error: ‘posix_memalign’ was not declared in this scope
make[2]: *** [common/CMakeFiles/common.dir/common.cpp.o] Error 1

The build log is attached.

Attachments (1)

main.log (261.0 KB) - added by zzanderr 9 years ago.

Download all attachments as: .zip

Change History (15)

Changed 9 years ago by zzanderr

Attachment: main.log added

comment:1 Changed 9 years ago by zzanderr

NB. Something tells me that x265 is asking a bit too much for a 1.6 GHz single core PPC. On the other hand, I need it now for ffmpeg, which has served me well to date.

comment:2 in reply to:  1 ; Changed 9 years ago by dbevans (David B. Evans)

Cc: devans@… added; ays388@… removed
Owner: changed from macports-tickets@… to ays388@…

Replying to zanderpower@…:

NB. Something tells me that x265 is asking a bit too much for a 1.6 GHz single core PPC. On the other hand, I need it now for ffmpeg, which has served me well to date.

Do you mean for the build, or for processing video after it's built?

comment:3 Changed 9 years ago by dbevans (David B. Evans)

Since there seem to be some issues with x265 particularly on the older machines, perhaps x265 should be made optional for ffmpeg for now or perhaps just enabled on the newer OS versions where it builds until these issues are ironed out. Any objections? Does it attempt to provide support for ppc processors? If so, I assume it doesn't need yasm in the ppc environment. See #40154 where this issue was raised for libvpx.

comment:4 in reply to:  2 ; Changed 9 years ago by zzanderr

Replying to devans@…:

Replying to zanderpower@…:

NB. Something tells me that x265 is asking a bit too much for a 1.6 GHz single core PPC. On the other hand, I need it now for ffmpeg, which has served me well to date.

Do you mean for the build, or for processing video after it's built?

I'm not worried about the time it takes to build anything! I just am not sure that PPC can handle extreme HD video very smoothly. I only need to (lossy) compress the really high bit-rate stuff.

To answer your second question, I'm OK with it being optional until the issue is addressed. I will need to dig a little to find out whether there is any support in x265 for PPC. I'll see if I can answer this question for you.

Thanks for the quick response.

comment:5 in reply to:  4 Changed 9 years ago by dbevans (David B. Evans)

Replying to zanderpower@…:

I'm not worried about the time it takes to build anything! I just am not sure that PPC can handle extreme HD video very smoothly. I only need to (lossy) compress the really high bit-rate stuff.

I'm thinking that it may take some processing time to compress video but the playback should not be too bad (similar to x264). If you look at the video samples available on x265.org, x265 (hevc) provides the most dramatic improvements in visual quality over x264 for low bit rates.

To answer your second question, I'm OK with it being optional until the issue is addressed. I will need to dig a little to find out whether there is any support in x265 for PPC. I'll see if I can answer this question for you.

I really was directing this to the x265 maintainer but any info you can find would help in determining what the platform constraints are. My old ppc machine died some time ago and since then I have had to rely on folks like you do the testing necessary to support the older OS versions and architectures.

I'll probably make x265 support on ffmpeg, ffmpeg-devel optional via variant for now so as not to block building on these platforms.

comment:6 Changed 9 years ago by zzanderr

From what I have gleaned, it seems that x265 is unstable--at best--on PowerPCs. Seehttps://bitbucket.org/multicoreware/x265/issues/85/fallback-for-atomic-ops-usage and http://www.calculate-linux.org/packages/media-libs/x265 and these examples appear to be referring to 64-bit (running Linux at that).

The most optimistic info I have found so far is https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/w_gcORP9768. And as before, this is (Debian) Linux.

I don't know if this gives you any ideas. I'm not sure what they mean by "atomic", unless there is some assembly code that must be implemented to work around the problem, or some library that needs to be linked ("-latomic"?).

Again, I am fine with a ffmpeg variant that lacks x265, until another option becomes viable (if it ever does).

comment:7 Changed 9 years ago by ays388@…

x265 requires at least snow leopard, due to the use of posix_memalign() which was not available on leopard and lower.

comment:8 in reply to:  7 Changed 9 years ago by dbevans (David B. Evans)

Replying to ays388@…:

x265 requires at least snow leopard, due to the use of posix_memalign() which was not available on leopard and lower.

If there is no work around for this, then you probably should include a test for darwin version in an early phase of port processing (pre-fetch, pre-configure) and error out with an informative message when appropriate rather than just failing to build.

comment:9 Changed 9 years ago by udbraumann

Cc: braumann@… added

Cc Me!

comment:10 Changed 9 years ago by dbevans (David B. Evans)

As promised, ffmpeg, ffmpeg-devel updated in r138604. Now only builds with libx265 support if +libx265 variant is selected. The variant is only available for non-universal builds on 10.6 or later due to issues with x265. See also #48331, #48338.

comment:11 in reply to:  10 Changed 9 years ago by zzanderr

Replying to devans@…:

As promised, ffmpeg, ffmpeg-devel updated in r138604. Now only builds with libx265 support if +libx265 variant is selected. The variant is only available for non-universal builds on 10.6 or later due to issues with x265. See also #48331, #48338.

Thanks for your work and time.

comment:12 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

gstreamer1-gst-plugins-bad workaround in r148970

comment:13 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from ays388@… to macports-tickets@…
Status: newassigned

comment:14 Changed 4 years ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.