|
Description
Michael Weber (RETIRED)
2012-06-18 02:48:26 UTC
Created attachment 317476 [details]
patch fail log (omxplayer-9999-wrapper.patch.out)
Ebuild fails to apply patch: omxplayer-9999-wrapper.patch
I've submitted a bug report with revised Makefile and wrapper patches: https://bugs.gentoo.org/show_bug.cgi?id=442832 *** Bug 442832 has been marked as a duplicate of this bug. *** *** Bug 442834 has been marked as a duplicate of this bug. *** Please attach all your patches/comment on improvements here rather than opening new bug reports for packages we do not support (yet). Created attachment 329328 [details]
omxplayer-9999-Makefile.patch
Revised Makefile patch
Created attachment 329330 [details]
omxplayer-9999-wrapper.patch
Revised wrapper patch
Created attachment 329332 [details]
omxplayer-9999.ebuild
Looks like the package also required dev-libs/boost
I've added the missing required package.
There's still a missing library in OMXAudio.cpp, I've posted the output here: http://pastebin.com/GAgycfck (In reply to comment #9) > There's still a missing library in OMXAudio.cpp, I've posted the output > here: http://pastebin.com/GAgycfck Sorry, the above link will expire in a month, I've reposted the output in a permanent pastebin.0 http://pastebin.com/jWruyBTQ Created attachment 329644 [details] omxplayer-9999.ebuild Ok, list of things this revised ebuild fixes: - Add requirement for gcc-4.6 or higher - according to the developer, this packages requires it: https://github.com/huceke/omxplayer/issues/71 - Added requirement for dev-libs/boost - Added requirement for media-libs/freetype - Changed dodoc line from README to README.md - And finally, added information lines about needing to upgrade the Raspberry Pi firmware if ebuild fails with a specific error. Created attachment 329646 [details]
omxplayer-9999-Makefile.patch
Issues this Makefile patch fixes:
- Added missing -std=c++0x flag
- Added missing include for freetype2 library
The two above attachments should fix the existing issues. I was able to successfully compile on my local Raspberry Pi. (In reply to comment #13) > The two above attachments should fix the existing issues. > > I was able to successfully compile on my local Raspberry Pi. Sorry, I meant all 3 attachments should fix all existing issues. I was still experiencing troubles with current files, but following resolved issue for me: Adding freetype2 to the end of +LIBS string in omxplayer-9999-Makefile.patch, Here is entire +LIBS string which worked for me: +LIBS=-L/opt/vc/lib -lrt -lbcm_host -lopenmaxil -lvcos -lvchiq_arm -lGLESv2 -lkhrn_static $(shell pkg-config --libs libavcodec libavfilter libavformat libpcre freetype2) For some reason, I could not get gcc-4.6 ~arm to get through the linking phase. One of the fortran libraries kept failing. I had USE="-fortran" .. which is probably ok for the PI anyway (globally even). (distcc etc all disabled here). After suffering through that, about 20 hours to fail, twice, and 30 hours to build successfully, I checked out the code and it looks like the only thing it needs gcc-4.6 for is to add the support for subtitles. There's an error handling file that does something funny with extending the exception classes and gcc-4.5 doesn't have the same signatures. And that piece is only used by the two files for subtitles. So if you don't care about subtitles and are impatient, it would far faster to just hack that out of the project and continue to use gcc-4.5 stable. Created attachment 333212 [details, diff] Added freetype library to LIBS in makefile - nper c.encv@gmail.com Per nc.encv@gmail.com the freetype2 library needed to be added to the LIBS line in the makefile. Couldn't hurt, so I did it anyway. Created attachment 333214 [details]
omxplayer-9999-Makefile.patch
Attachment name was ugly... reuploaded. ;)
(In reply to comment #16) > For some reason, I could not get gcc-4.6 ~arm to get through the linking > phase. One of the fortran libraries kept failing. I had USE="-fortran" .. > which is probably ok for the PI anyway (globally even). (distcc etc all > disabled here). > > After suffering through that, about 20 hours to fail, twice, and 30 hours to > build successfully, I checked out the code and it looks like the only thing > it needs gcc-4.6 for is to add the support for subtitles. There's an error > handling file that does something funny with extending the exception classes > and gcc-4.5 doesn't have the same signatures. And that piece is only used > by the two files for subtitles. > > So if you don't care about subtitles and are impatient, it would far faster > to just hack that out of the project and continue to use gcc-4.5 stable. Subtitles are necessary for me (actually, near paramount since I watch anime with it). Can you post your use flags so I can compare, maybe something needs to be added to the e-build use flag requirements. (In reply to comment #16) > For some reason, I could not get gcc-4.6 ~arm to get through the linking > phase. One of the fortran libraries kept failing. I had USE="-fortran" .. > which is probably ok for the PI anyway (globally even). (distcc etc all > disabled here). > > After suffering through that, about 20 hours to fail, twice, and 30 hours to > build successfully, I checked out the code and it looks like the only thing > it needs gcc-4.6 for is to add the support for subtitles. There's an error > handling file that does something funny with extending the exception classes > and gcc-4.5 doesn't have the same signatures. And that piece is only used > by the two files for subtitles. > > So if you don't care about subtitles and are impatient, it would far faster > to just hack that out of the project and continue to use gcc-4.5 stable. I just had a chance to check my Pi's USE flags, and I have the fortran flag turned on. When you can, post your use flags. Created attachment 333230 [details]
omxplayer-9999.ebuild
Apparently the warning message about upgrading firmware was *NOT* in e-build, this has been now attached.
I tried stripping out the subtitle code, but it didn't work for my application (just got errors when trying to open stream from plex when using project pyplex from github). Not sure if this is because of the subtitles, but I figure it probably is. OR I did something stupid with my hackjob to pull the subtitle code out. Tried just using gcc 4.6.3 But updating to gcc 4.6 adds additional problems. It pulls in glibc 2.16, which violates the latest stable version of boost. I could not get newer versions of boost from portage tree to build. Building all of this takes way too long on rpi, so I used crossdev toolchain pointing to sshfs root of rpi with SYSROOT. Built and installed gcc 4.6.3 successfully, but cannot run it because it is missing libiconv. Working on fixing that now. As for boost, I copied dead ebuilds for boost 1.50. Built and merged as described above w/ crossdev with no problems. glibc is regenerating locales right now... after that I'll merge the binary package for libiconv and try rebuilding omx. If I get it to work I'll update the ebuild. Thanks for your work everyone, stumbling across this page was like striking oil! Successfully compiled and ran it to playback a stream generated from Plex Media Server. The key was using the built-in ffmpeg instead of using Gentoo's. I'll be submitted a modified ebuild and patches for this if anyone is interested. I guess everyone is interested, please commit anything that may help others :) Hey, so I have it building and streaming works as I mentioned. I am in the process of making the ebuilds. Since I couldn't get the gentoo ffmpeg to compile I made my own ffmpeg ebuild to use the one from the omxplayer. It's working well: https://github.com/dalehamel/PlexOverlay/blob/master/media-video/omxplayer-ffmpeg/omxplayer-ffmpeg-9999.ebuild It is a dependency of https://github.com/dalehamel/PlexOverlay/blob/master/media-video/omxplayer/omxplayer-9999.ebuild, which just needs to be modified to link to it (building is slow on the RPi). Keep an eye on https://github.com/dalehamel/PlexOverlay, I should have cleaned up and ready to go by tonight (at work right now). As of this morning I have it building. Just adding it to a PORTDIR_OVERLAY and emerging omxplayer will automatically pull in omxplayer-ffmpeg. Omxplayer has been recently updated, but I have frozen support in the ebuild to the Dec 4th revision. I'll be looking into what needs to be done to get it to work with the latest upstream. Otherwise, enjoy the repo! There's a build of omxplayer that supports built-in subtitles. Can we merge that capability in with your build Dale? https://github.com/huceke/omxplayer/issues/59#issuecomment-11174254 to build this , one need gcc-4.7 now
also the patches dont apply anymore i tried to 'fix' them , they apply now but it wont build:
n file included from /usr/include/sys/stat.h:106:0,
from linux/PlatformDefs.h:37,
from ./system.h:227,
from utils/log.cpp:22:
/usr/include/bits/stat.h:72:21: error: field 'st_atim' has incomplete type
/usr/include/bits/stat.h:73:21: error: field 'st_mtim' has incomplete type
/usr/include/bits/stat.h:74:21: error: field 'st_ctim' has incomplete type
/usr/include/bits/stat.h:118:21: error: field 'st_atim' has incomplete type
/usr/include/bits/stat.h:119:21: error: field 'st_mtim' has incomplete type
/usr/include/bits/stat.h:120:21: error: field 'st_ctim' has incomplete type
In file included from ./system.h:227:0,
from utils/log.cpp:22:
linux/PlatformDefs.h:380:3: error: 'time_t' does not name a type
linux/PlatformDefs.h:381:3: error: 'time_t' does not name a type
linux/PlatformDefs.h:382:3: error: 'time_t' does not name a type
In file included from /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/bits/locale_facets_nonio.h:39:0,
from /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/locale:43,
from utils/StdString.h:670,
from DynamicDll.h:24,
from DynamicDll.cpp:22:
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:62:11: error: '::clock_t' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:63:11: error: '::time_t' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:66:11: error: '::clock' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:67:11: error: '::difftime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:68:11: error: '::mktime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:69:11: error: '::time' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:70:11: error: '::asctime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:71:11: error: '::ctime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:72:11: error: '::gmtime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:73:11: error: '::localtime' has not been declared
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.2/include/g++-v4/ctime:74:11: error: '::strftime' has not been declared
I did some searching and think this is due ffmpeg-1.x including a modified time.h causing these conflicts. When building with <ffmpeg-1.x , there is an other error
Created attachment 345156 [details, diff]
omxplayer-9999-Makefile.patch
omxplayer-9999-Makefile.patch
Created attachment 345158 [details, diff]
omxplayer-9999-wrapper.patch
Experiencing `OMXReader.cpp:499:49: error: 'AV_CODEC_ID_SUBRIP' was not declared in this scope` here with =media-video/ffmpeg-0.10.6. If we look at https://github.com/huceke/omxplayer/blob/master/Makefile.ffmpeg#L64 we can see that commit 8c51ea54897c2d8671b38efecc1422ad4ad344f9 is used for ffmpeg. That commit seems to have been made on September 20, 2013; this is a commit some months before 0.10.6 has been released and some days before 1.0 has been released. Therefore the version used is likely not in our Portage tree. The only relevant bug I can find is people wanting to see ffmpeg as a sub module (https://github.com/huceke/omxplayer/pull/113), therefore I have filed another bug to request the code to be updated to work with newer versions (https://github.com/huceke/omxplayer/issues/155). The only way to get it to work currently is to bundle ffmpeg unless someone feels like patching the code (please update above issue 155 in that case), but given the limited embedded environment it's a bit nasty to keep around multiple versions; so, one may opt to pull in that specific commit for media-video/ffmpeg. i havent had the time yet to test but https://github.com/huceke/omxplayer/issues/150 says it nows support ffmpeg1.2 , maybe one could try to build against that, i might try myself later this week ... Since I had 2 more problems which I fixed in the omxplayer-9999.Makefile.patch. You can read the details on https://forums.gentoo.org/viewtopic-t-967632.html. I will supply the patch in the next comment. Created attachment 356570 [details, diff]
Makefile patch eliminating libavutil and libswresample build errors
This is basically the patch supplied by the xmw overlay with fixes for libavutil and libswresample.
I just tried to build omxplayer on my Raspberry Pi. It fails with a lot of suspect errors like:
In file included from /usr/include/sys/stat.h:106:0,
from linux/PlatformDefs.h:37,
from ./system.h:227,
from utils/log.cpp:22:
/usr/include/bits/stat.h:72:21: error: field ‘st_atim’ has incomplete type
...
In file included from ./system.h:227:0,
from utils/log.cpp:22:
linux/PlatformDefs.h:380:3: error: ‘time_t’ does not name a type
...
In file included from /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.3/include/g++-v4/bits/locale_facets_nonio.h:39:0,
from /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.3/include/g++-v4/locale:43,
from ./utils/StdString.h:670,
from utils/log.cpp:26:
/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.3/include/g++-v4/ctime:62:11: error: ‘::clock_t’ has not been declared
(see the attached build.log and emerge --info).
Additionally, https://github.com/huceke/omxplayer says: "This tree is no longer under active delevopment. Updates will occur here: https://github.com/popcornmix/omxplayer". Perhaps the ebuild should be updated to use the new code location?
Created attachment 376422 [details]
The build.log of the failed build
Created attachment 376424 [details]
The emerge --info of the failed build
I've bumped the some ebuilds in my dev overlay (layman -s xmw), current state
# emerge -pv raspberrypi-{firmware,userland-bin} omxplayer
[ebuild R #] media-libs/raspberrypi-userland-bin-1_pre20150421::xmw USE="hardfp -examples" 0 KiB
[ebuild R #] sys-boot/raspberrypi-firmware-1_pre20150421::xmw 0 KiB
[ebuild R ~] media-video/omxplayer-0_p20150421::xmw 0 KiB
maybe X? ( x11-apps/xrefresh ) as this package does not have a maintainer, i'll take it as i need it myself. i improved the ebuild and put it in the main tree: commit 5e1dbb3f8a38fb9a91420a0f8da75efd2172a07d Author: Miroslav Šulc <fordfrog@gentoo.org> Date: Tue Mar 8 22:08:32 2016 +0100 media-video/omxplayer: adjusted and improved ebuild from bug #421683 Package-Manager: portage-2.2.27 i'll leave this bug open for a while so you can report back any issues. as suggested by steev at #gentoo-dev, renamed omxplayer to raspberrypi-omxplayer Created attachment 435900 [details, diff]
Depend on boost and freetype2, added X use flag
With a bare bones, frame buffer-only build without X, boost and freetype2 will be missing.
Also remove dependency on xrefresh and xset if X is disabled via use flag.
(In reply to Ahmet Inan from comment #42) > Created attachment 435900 [details, diff] [details, diff] > Depend on boost and freetype2, added X use flag > > With a bare bones, frame buffer-only build without X, boost and freetype2 > will be missing. > Also remove dependency on xrefresh and xset if X is disabled via use flag. thanks for the patch. commit 7a9f821787a21db585ae1bee8c5f1facda2d3254 Author: Miroslav Šulc <fordfrog@gentoo.org> Date: Tue May 31 14:34:08 2016 +0200 media-video/raspberrypi-omxplayer: applied patch by Ahmet Inan <xdsopl@googlemail.com> from bug #421683 and bumped to the latest sources Package-Manager: portage-2.3.0_rc1 Created attachment 436156 [details, diff]
Fix Makefile patching for raspberrypi-omxplayer-0_p20160528
They have added vchostif to the linker list so the previous Makefile patch will fail. Copied and hand-edited the patch to include " -lvchostif".
Created attachment 436158 [details, diff] Fix ebuild raspberrypi-omxplayer-0_p20160528 They have added " -lvchostif" to the linker list but screwed with the order. The previous Makefile patch takes care of removing the linker list and this ebuild creates the Makefile.include with the correct order, for static and dynamic vchostif lib. Also see https://github.com/popcornmix/omxplayer: commit 7ad3761e9bf33a442e63e8e3d8a2429c94329294 Makefile: Explicitly link with vchostif library (In reply to Ahmet Inan from comment #45) > Created attachment 436158 [details, diff] [details, diff] > Fix ebuild raspberrypi-omxplayer-0_p20160528 > > They have added " -lvchostif" to the linker list but screwed with the order. > The previous Makefile patch takes care of removing the linker list and this > ebuild creates the Makefile.include with the correct order, for static and > dynamic vchostif lib. Also see https://github.com/popcornmix/omxplayer: > > commit 7ad3761e9bf33a442e63e8e3d8a2429c94329294 > Makefile: Explicitly link with vchostif library thanks for the fix. commit 53eace1f6281067889b6200682253e5c43941a79 Author: Miroslav Šulc <fordfrog@gentoo.org> Date: Thu Jun 2 11:30:17 2016 +0200 media-video/raspberrypi-omxplayer: applied makefile fix from Ahmet Inan <xdsopl@googlemail.com> from bug #421683 comment #44 and #45 Package-Manager: portage-2.3.0_rc1 |