Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 341849 - media-video/ffmpeg-0.6_p25423 fails src_test "Some tests in codectest failed"
Summary: media-video/ffmpeg-0.6_p25423 fails src_test "Some tests in codectest failed"
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Media-video project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-20 04:44 UTC by Kent Fredric (IRC: kent\n) (RETIRED)
Modified: 2010-11-07 22:32 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2010-10-20 04:44:44 UTC
>>> Starting src_test
make --jobs=3 codectest
HOSTCC	tests/base64.o
HOSTCC	tests/tiny_psnr.o
HOSTCC	tests/audiogen.o
HOSTCC	tests/videogen.o
tests/videogen.c: In function 'pgmyuv_save':
tests/videogen.c:116: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
tests/videogen.c:122: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
tests/videogen.c:123: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
HOSTCC	tests/rotozoom.o
HOSTCC	tests/base64
tests/rotozoom.c: In function 'pgmyuv_save':
tests/rotozoom.c:140: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
tests/rotozoom.c:146: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
tests/rotozoom.c:147: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
tests/rotozoom.c: In function 'init_demo':
tests/rotozoom.c:255: warning: ignoring return value of 'fread', declared with attribute warn_unused_result
tests/rotozoom.c:257: warning: ignoring return value of 'fread', declared with attribute warn_unused_result
HOSTCC	tests/tiny_psnr
HOSTCC	tests/audiogen
HOSTCC	tests/videogen
HOSTCC	tests/rotozoom
GEN	tests/data/asynth1.sw
GEN	tests/vsynth1/00.pgm
GEN	tests/vsynth2/00.pgm
GEN	tests/data/acodec.ref.wav
make: *** [tests/data/acodec.ref.wav] Error 127
make: *** Waiting for unfinished jobs....


Error:
  * In program cave perform install --hooks --managed-output --output-exclusivity with-others =media-video/ffmpeg-0.6_p25423:0::gentoo --destination installed --replacing =media-video/ffmpeg-0.6:0::installed --x-of-y 3 of 3:
  * When installing 'media-video/ffmpeg-0.6_p25423:0::gentoo' replacing { 'media-video/ffmpeg-0.6:0::installed' }:
  * When running an ebuild command on 'media-video/ffmpeg-0.6_p25423:0::gentoo':
  * Install failed for 'media-video/ffmpeg-0.6_p25423:0::gentoo' (paludis::ActionFailedError)

/usr/libexec/paludis/utils/emake: emake returned error 2

!!! ERROR in media-video/ffmpeg-0.6_p25423::gentoo:
!!! In src_test at line 4400
!!! Some tests in codectest failed

!!! Call stack:
!!!    * src_test (/tmp/portage/media-video-ffmpeg-0.6_p25423/temp/loadsaveenv:4400)
!!!    * ebuild_f_test (/usr/libexec/paludis/2/src_test.bash:74)
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:647)
!!!    * main (/usr/libexec/paludis/ebuild.bash:675)


In my initial investigation, I found this: 

/tmp/portage/media-video-ffmpeg-0.6_p25423/work/ffmpeg-0.6_p25423/ffmpeg: error while loading shared libraries: libavcore.so.0: cannot open shared object file: No such file or directory

in  tests/data/aref.acodec.err  

and upon further testing, 

# ./ffmpeg --help
./ffmpeg: error while loading shared libraries: libavcore.so.0: cannot open shared object file: No such file or directory

Confirms this ffmpeg looks pretty much broken as-is.

qlist media-video/ffmpeg | grep -i avcodec.so

/usr/lib64/libavcodec.so.52
/usr/lib64/libavcodec.so
/usr/lib64/debug/usr/lib64/libavcodec.so.52.72.2.debug
/usr/lib64/libavcodec.so.52.72.2

qlist media-video/ffmpeg | grep -i avcore 
<no output>

So there is no avcore in previous releases.

These are the actions I will take, in order:

u   media-video/ffmpeg:0::gentoo 0.6_p25423 installed replacing 0.6
    3dnow 3dnowext X alsa (-altivec) -amr -bindist bzip2+ -cpudetection -custom-cflags -debug dirac -doc encode faac -frei0r+ gsm hardcoded-tables -ieee1394 -jack jpeg2k mmx mmxext mp3 network -oss -pic -qt-faststart+ rtmp schroedinger sdl speex ssse3 -static-libs+ theora threads v4l v4l2 vaapi vdpau vorbis vpx x264 xvid zlib (test) VIDEO_CARDS: nvidia build_options: optional_tests split strip -trace -preserve_work
    Reasons: target, media-libs/xine-lib


LD_LIBRARY_PATH="$PWD/libavcore" ./ffmpeg --help
./ffmpeg: relocation error: /tmp/portage/media-video-ffmpeg-0.6_p25423/work/ffmpeg-0.6_p25423/libavcore/libavcore.so.0: symbol av_default_item_name, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference

And that doesn't look too good either. 



emerge --info =media-video/ffmpeg-0.6_p25423

https://gist.github.com/raw/5a3248aef2e3c7dc428e/3cda9bcaa7bc36bbdb0da05fcd5e62469142812c/emerge%20--info%20=media-video_ffmpeg-0.6_p25423

cave info =media-video/ffmpeg-0.6_p25423 

https://gist.github.com/raw/5a3248aef2e3c7dc428e/0aa10d602cddaa72e4d4740c64c09fd771ca4619/cave%20info%20=media-video_ffmpeg-0.6_p25423

/var/log/paludis/1287516176-install-media-video_ffmpeg-0.6_p25423:0::gentoo.out

https://gist.github.com/raw/5a3248aef2e3c7dc428e/dacf1f73e05cc1ccd51e0b818c63b7bef241f8eb/_var_log_paludis_1287516176-install-media-video_ffmpeg-0.6_p25423:0::gentoo.out

config.log

https://gist.github.com/raw/5a3248aef2e3c7dc428e/57d6b1f8888bcf5ae435d1873048b74f65ade09a/config.log
Comment 1 Reimar Döffinger 2010-10-23 18:53:58 UTC
What the...? Is the ebuild running the tests in a way that the newly compiled ffmpeg binary will use the installed libraries?
Note that either you have to support tests only for statically linked versions or you will have to do whatever is necessary to make the OS select the newly compiled .so to run the FFmpeg binary.
The build system doesn't take care of the latter since there is no way to do so in a portable way.
Comment 2 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2010-10-24 14:04:49 UTC
(In reply to comment #1)
> What the...? Is the ebuild running the tests in a way that the newly compiled
> ffmpeg binary will use the installed libraries?
Not sure.
> Note that either you have to support tests only for statically linked versions
> or you will have to do whatever is necessary to make the OS select the newly
> compiled .so to run the FFmpeg binary.
> The build system doesn't take care of the latter since there is no way to do so
> in a portable way.
> 

I tried with and without "static-libs" use flag, and it appeared to have no impact. I think I'll try a testless install of it and see what occurs. But my gut/instinct seems to think I'll get either a broken ffmpeg install, or that the ffmpeg build being used to run the tests differs from the one installed. 



Comment 3 Reimar Döffinger 2010-10-24 15:24:03 UTC
> I tried with and without "static-libs" use flag

I don't think that will link the FFmpeg binary statically.
To test if this is the issue you'd have to set LD_LIBRARY_PATH to the directories where portage builds the libav*.so libraries (or disable compilation of the *.so completely, but I don't think the ebuild supports that).
Comment 4 Alexis Ballier gentoo-dev 2010-11-07 20:35:01 UTC
(In reply to comment #1)
> What the...? Is the ebuild running the tests in a way that the newly compiled
> ffmpeg binary will use the installed libraries?

yes; I updated LD_LIBRARY_PATH to know about libavcore when running the tests too so that this wont happen anymore
Comment 5 Reimar Döffinger 2010-11-07 20:44:42 UTC
Doesn't emerge run "make install" at some point? Wouldn't it then be simpler and safer to run the tests after that, since all libraries are then in the same path?
Of course I don't expect FFmpeg to add libraries particularly often so it's a minor thing, but it seems nicer though.
Comment 6 Alexis Ballier gentoo-dev 2010-11-07 20:47:28 UTC
it would be simpler yes, but tests are ran before make install:
http://devmanual.gentoo.org/ebuild-writing/functions/index.html

so we do not really have a choice...
Comment 7 Reimar Döffinger 2010-11-07 21:22:14 UTC
It would not be impossible to have a pre-install and post-install test :-).
Not claiming that this will actually make sense, just something worth considering if someone has the time and inclination...
Comment 8 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2010-11-07 22:32:39 UTC
(In reply to comment #7)
> It would not be impossible to have a pre-install and post-install test :-).
> Not claiming that this will actually make sense, just something worth
> considering if someone has the time and inclination...
> 

It would be reasonably nasty, and I for one don't wish to see that happen. Running tests outside src_test(){ }  sounds like fail to me.

Getting it to work right with FEATURES="test" and FEATURES="-test", yuck.