This is mentioned in http://bugs.gentoo.org/show_bug.cgi?id=279944, but it's not the reason that bug was filed so I am filing this new one. There is some issue with the included libavcodec which prevents compilation. It looks like this is not a new issue, see here: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/92570/focus=92606 I will attach the relevant logs, but the above link shows the same error I am getting when I compile on x86 w/ GCC 4.4.2. The above link indicates that this can be expected on anything >=4.2 I've tried editing the ebuild to use my own CFLAGS and also to disable mmx - the latter causes a failure warning that mythtv would be too slow w/o mmx.
Created attachment 209648 [details] build log - this one should use locally-defined CFLAGS
Created attachment 209650 [details] emerge --info
Created attachment 209652 [details] emerge --pqv
Well, you should take a look at bug 290741. Disabling mmx assembly in ffmpeg gets around the problem.
I confirm this bug on my 32 bit athlon-xp. Looks like mythtv builds on my amd64 boxes though.
(In reply to comment #5) > I confirm this bug on my 32 bit athlon-xp. Looks like mythtv builds on my > amd64 boxes though. > It's only affecting x86, evidently because gcc runs out of registers to allocate when trying to compile some code with inline asm. If I edit ${WORKDIR}/branches/mythtv-0.22-fixes/mythtv/libs/libavcodec/Makefile to remove all reference to -DPIC -fPIC I am able to get the source to compile and merge by ebuilding directly. I had to remove mythtv-themes and mythcontrols prior to merge to avoid collisions. Right now I am using 0.22 to watch a recorded show - so I guess it worked. I am not sure if this is safe to do, since I think it's not recommended to mix PIC and not-PIC. Maybe the ebuilds need to expose the pic use flag to allow it to be disabled more easily. Unrelated note: I had to edit my mysql config and do a backup/drop/edit/restore of my 0.21 database in order to get 0.22 to work. The error messages logged in /var/log/mythtv/mythbackend.log were enough to point me to the correct info for doing this. I will leave this open in case we want to change the ebuilds to expose pic or 'solve' this is some other way.
I do also confirm this bug on my x86 core2duo ... Although I still don't get it emerged. Do I understand correctly: ffmpeg should be reemerged with USE="-pic" before emerging mythtv ? I haven't got mythtv emerged yet, even after rebuilding ffmpeg. I currently re-emerge stuff after adding "-pic" to my USE-variable in make.conf. Although equery told me that I didn't have any pkgs with "pic" installed.
(In reply to comment #7) > I do also confirm this bug on my x86 core2duo ... > Although I still don't get it emerged. > > Do I understand correctly: ffmpeg should be reemerged with USE="-pic" before > emerging mythtv ? I haven't got mythtv emerged yet, even after rebuilding > ffmpeg. > > I currently re-emerge stuff after adding "-pic" to my USE-variable in > make.conf. Although equery told me that I didn't have any pkgs with "pic" > installed. > No. I was suggesting that the relevant ebuilds SHOULD expose the pic useflag - they do not right now. Also MythTV includes libavcodec in its source distribution. What worked for me: 1. ebuild /usr/portage/media-tv/mythtv/mythtv-0.22_p22772.ebuild configure 2. edit /var/tmp/portage/media-tv/mythtv/mythtv-0.22_p22772/work/branches/release-0-22-fixes/mythtv/libs/libavcodec/Makefile and remove "-DPIC -fPIC" anywhere you see it 3. ebuild /usr/portage/media-tv/mythtv/mythtv-0.22_p22772.ebuild compile 4. emerge -C mythtv-themes-extra mythtv-themes mythcontrols mythtv 5. ebuild /usr/portage/media-tv/mythtv/mythtv-0.22_p22772.ebuild merge 6. emerge -uND mythtv-themes <+ additional list of mythtv-plugins> I had to do #4 above because of complaints about file collisions. Again, I also had to backup my database and convert it to use latin1 encoding. This was not hard, reference http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding and http://www.mythtv.org/wiki/Database_Backup_and_Restore whenever the mythtv site starts working properly again.
(In reply to comment #8) > What worked for me: > > 1. ebuild /usr/portage/media-tv/mythtv/mythtv-0.22_p22772.ebuild configure > 2. edit > /var/tmp/portage/media-tv/mythtv/mythtv-0.22_p22772/work/branches/release-0-22-fixes/mythtv/libs/libavcodec/Makefile > and remove "-DPIC -fPIC" anywhere you see it Hmm, step 1 gives me the path /var/tmp/portage/media-tv/mythtv-0.22_p22772/work/branches/release-0-22-fixes/mythtv/libs/libavcodec and there is no Makefile there now to edit ... > Again, I also had to backup my database and convert it to use latin1 encoding. I have done that already, yes. Thanks for your help ...
(In reply to comment #9) > Hmm, step 1 gives me the path > > /var/tmp/portage/media-tv/mythtv-0.22_p22772/work/branches/release-0-22-fixes/mythtv/libs/libavcodec > > and there is no Makefile there now to edit ... Ok, got that Makefile now and edited it (I had to run that emerge-step first, wait for the crash, then edit the Makefile). It seems to run through now ...
(In reply to comment #10) > Ok, got that Makefile now and edited it (I had to run that emerge-step first, > wait for the crash, then edit the Makefile). It seems to run through now ... OK, it emerged now. For me the file in init.d was not created and when I manually did what the ebuild said, the path to mythbackend was wrong, it now is located in /usr/local/bin instead of /usr/bin. Now I had to partially restore my backups after hitting another issue :-(
I modified the ebuild to change the eqmake4 to qmake, per the later posts of http://forums.gentoo.org/viewtopic-t-798703-start-25.html Worked a treat. I don't know what the difference is, but I'm finally using mythtv 0.22, wonderful job guys!
This seems to be a duplicate of bug #279944
(In reply to comment #13) > This seems to be a duplicate of bug #279944 > It may be, as noted in my original bug report. However, 279944 presents different errors and I was not sure that they were caused by the same issue.
This issue might be fixed by 0.22_p22860, please test and report.
Fixed with 0.22_p22860.
*** Bug 293744 has been marked as a duplicate of this bug. ***
