If you have emerged faad2, the ebuild for gtkpod will through hundreds of syntax errors when it encounters the mp4file handling code. With faad2 installed, the ebuild automatically adds in mp4 file support. Reproducible: Always Steps to Reproduce: 1. emerge faad2 2. emerge gtkpod 3. Actual Results: During the config output, make indicates that: mp4v2 ..............: yes -- will build with aac support You then see later: In file included from mp4file.c:110: /usr/include/mp4.h:43:error syntax error before "MP4TrackId" (many, many, many other syntax errors follow) Expected Results: Either 1 -- it should build correctly with faad2 installed, or 2 -- give the user the option in the ebuild to not include mp4 support with a USE="-mp4" option I think that's the easiest way to handle this one. Thus, users can still get gtkpod built without having to depend on some subtle differences between the two implementations of mp4 support, it appears.
mpeg4ip and faad2 seem to provide some of the same files, but are not replacement one with the other.. I'll try to see if there is a way to fix this.. Faad2 is depended on by 4 packages and mpeg4ip only by gtkpod, but mpeg4ip is more than just a library, it has a player and a streaming server too. So its probably easier to change mpeg4ip... but its a bit more complicated since the mpeg4ip.h provided by faad2 comes from mpeg4ip.. but has been modified (I think..) Those are included in both.. /usr/include/mp4.h /usr/include/mpeg4ip.h /usr/lib/libmp4v2.a /usr/lib/libmp4v2.la /usr/lib/libmp4v2.so /usr/lib/libmp4v2.so.0 /usr/lib/libmp4v2.so.0.0.0 It seems that the .so files are compatible (at least compatible enough for gtkpod to work).. So it might just be a .h problem.. I'll try to get more information...
solutions : blocking or virtuals. Afaik the mp4v2 versions can be interchanged, but the mpeg4ip pack is way too big to add as dep.
I agree that mpeg4ip is way too big to have as a dep of faad2.. but maybe we can do it the other way around.... Blocking/virtuals is not a solution because 80% of the stuff is not provided by both (I need both on my system..) And I believe that the mp4.h in faad2 is actually broken... but I haven't verified (so dont take my word for it)...
Seems like the files in faad2 are old files from mpeg4ip.. maybe we should make those files a common dep and break them into another package... which would use the mpeg4ip source...
Indeed faad2 is the problem, simple workaround : emerge -C faad2 ACCEPT_KEYWORDS="~x86" emerge gtkpod emerge faad2 *Note that mplayer won't run after uninstalling faad2. **New version of gtkpod-0.72-2 available but has the same problem with faad2 But just why is this not logged in the Bugs section on sourceforge.net where gtkpod is hosted? Isn't this a problem in the code of gtkpod and not of portage?
Yes, but that's not the issue. The average punter is not going to go to the sourceforge page to check it first. They're just going to emerge the ebuild, and then presto, they hit the bug. It just makes sense to put the flag into the ebuild, so that at least someone (like me) does not have to go hunting around for the workaround. As well, perhaps I don't want mp4 support. Maybe I don't like mp4. With the flag there, I have more power. So, it's not a bug in portage per se, more that IMHO the approach should be improved for the average Gentoo-er who's not out reading the sourceforge site _before_ they emerge. Nothing's worse then emerge -u world that fails halfway through. Oh, and as for sourceforge getting the bug, will do.
ok, I've patched gtkpod to compile against faad2 too.. And mpeg4ip now blocks faad2... so it should all be good.
