LinuxQuestions.org - I'm getting errors when trying to make install Mplayer. What is going wrong?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - I'm getting errors when trying to make install Mplayer. What is going wrong? (https://www.linuxquestions.org/questions/linux-newbie-8/im-getting-errors-when-trying-to-make-install-mplayer-what-is-going-wrong-212331/)

I'm getting errors when trying to make install Mplayer. What is going wrong?

Im trying to compile Mplayer from source and I get this when I try to make install. What is going wrong? This is at the end of the "make"

ffv1.c: In function `encode_rgb_frame':
ffv1.c:465: internal compiler error: in find_function_data, at function.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:https://qa.mandrakesoft.com/> for instructions.
make[1]: *** [ffv1.o] Error 1
make[1]: Leaving directory `/home/******/Desktop/MPlayer-1.0pre5/libavcodec'
make: *** [libavcodec/libavcodec.a] Error 2

This is the make install... Im stuck... Can anyone help me?

# make install
make -C libavcodec LIBPREF=lib LIBSUF=.a
make[1]: Entering directory `/home/******/Desktop/MPlayer-1.0pre5/libavcodec'
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=pentium4 -mcpu=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o ffv1.o ffv1.c
ffv1.c: In function `encode_rgb_frame':
ffv1.c:465: internal compiler error: in find_function_data, at function.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:https://qa.mandrakesoft.com/> for instructions.
make[1]: *** [ffv1.o] Error 1
make[1]: Leaving directory `/home/*****/Desktop/MPlayer-1.0pre5/libavcodec'
make: *** [libavcodec/libavcodec.a] Error 2

LOL, do you have the Gcc compiler installed?????

I dunno. Whats that? Do I have to install that? Can I just urpmi it?

I just did "urpmi gcc" and it said everything is already installed. I tried "urpmi gcc compiler" and it said their is no package with that name.

Hmm looks like this problem has cropped up before with ffmpeg (google). You might let us know which gcc you are using by entering gcc --version at the command prompt. I was able to compile mplayer with no problems using gcc 3.3.3

This is what I got.

gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Try upgrading to the latest ffmpeg (uninstall the rpm first)
http://ffmpeg.sourceforge.net

Same problem, same result

I have an identical problem, so I can confirm that this problem is real and not due to freak winds or bizarre hardware. Looks like the version of gcc is not compatible with the latest version of mplayer.

Solution... without new package

I'm a C programmer (amongst other things) so if you are not comfortable editing code then this solution is not for you. That said:

1. Edit .../libavcodec/ffv1.c
2. Find line 465 (the line mentioned in the error message)
3. Change:

Code:

sample[p][i]= sample_buffer[p][(h+i-y)%ring_size]+3;

Code:

{

        int tmp;

        tmp=(h+i-y)%ring_size;

        sample[p][i]= sample_buffer[p][tmp]+3;

}

Thanks for the code fix!
I was having the same problem compiling Mplayer, and didn't really want to have to upgrade gcc.

I can confirm that this code change does work. I made it, and was able to compile Mplayer without any other problems.

I hate to be the one to take the low road, but if you are using Mandrake 10, as your user tag suggests, why not just install the Mplayer RPM included on your installation CD-roms? :(

Mplayer has soooo many dependancies and codecs...

You make a valid point, but there is a reason.
I did install Mplayer from the CDs. That version is slower, probably because it was compiled with cpu-runtime-detection. It also always comes up fullscreen instead of in a window.

I have compiled it successfully in the past without much problem at all, so for me it isn't a big deal.