compile error: mplayer/libavcodec
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error: gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o utils.o utils.c In file included from utils.c:20: dsputil.h:277: warning: static declaration for `lrintf' follows non-static dsputil.h: In function `lrintf': dsputil.h:279: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions. make[1]: *** [utils.o] Error 1 make[1]: Leaving directory `/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 thanks - Nil
I deleted the word "static" in line 277 of libavcodec/dsputil.h . That fixed the compile problem. But I have no idea if thats the correct fix. thanks - Nil On Tue, 5 Nov 2002, Nilmoni Deb wrote:
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error:
gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o utils.o utils.c In file included from utils.c:20: dsputil.h:277: warning: static declaration for `lrintf' follows non-static dsputil.h: In function `lrintf': dsputil.h:279: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions. make[1]: *** [utils.o] Error 1 make[1]: Leaving directory `/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2
thanks - Nil
Well , the fix was only temporary as in the end, it failed anyway: gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibmpdemux -Iloader -Ilibvo -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/opt/sdl//include/SDL -D_REENTRANT -o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o cfgparser.o my_profile.o spudec.o playtree.o playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o unrarlib.o mixer.o libvo/libvo.a libao2/libao2.a vidix/libvidix.a Gui/libgui.a libmpcodecs/libmpcodecs.a mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a loader/libloader.a loader/dshow/libDS_Filter.a libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libpostproc.a postproc/libswscale.a linux/libosdep.a -Llibmpdvdkit2 -lmpdvdkit libavcodec/libavcodec.a -lpng -lz -lz -ljpeg -lnsl -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lglib -L/opt/sdl//lib -Wl,-rpath,/opt/sdl//lib -lSDL -lpthread -lGL -lXxf86dga -lXv -lXxf86vm -lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lnsl -L/usr/lib -ldl -lartsc -lpthread -lpthread -ldl -rdynamic -lm libavcodec/libavcodec.a(mpegvideo.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(h263.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(jrevdct.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(jfdctfst.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here On Tue, 5 Nov 2002, Nilmoni Deb wrote:
I deleted the word "static" in line 277 of libavcodec/dsputil.h . That fixed the compile problem. But I have no idea if thats the correct fix.
thanks - Nil
On Tue, 5 Nov 2002, Nilmoni Deb wrote:
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error:
gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o utils.o utils.c In file included from utils.c:20: dsputil.h:277: warning: static declaration for `lrintf' follows non-static dsputil.h: In function `lrintf': dsputil.h:279: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions. make[1]: *** [utils.o] Error 1 make[1]: Leaving directory `/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2
thanks - Nil
On Tue, 2002-11-05 at 07:26, Nilmoni Deb wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
Well , the fix was only temporary as in the end, it failed anyway:
gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibmpdemux -Iloader -Ilibvo -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/opt/sdl//include/SDL -D_REENTRANT -o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o cfgparser.o my_profile.o spudec.o playtree.o playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o unrarlib.o mixer.o libvo/libvo.a libao2/libao2.a vidix/libvidix.a Gui/libgui.a libmpcodecs/libmpcodecs.a mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a loader/libloader.a loader/dshow/libDS_Filter.a libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libpostproc.a postproc/libswscale.a linux/libosdep.a -Llibmpdvdkit2 -lmpdvdkit libavcodec/libavcodec.a -lpng -lz -lz -ljpeg -lnsl -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lglib -L/opt/sdl//lib -Wl,-rpath,/opt/sdl//lib -lSDL -lpthread -lGL -lXxf86dga -lXv -lXxf86vm -lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lnsl -L/usr/lib -ldl -lartsc -lpthread -lpthread -ldl -rdynamic -lm libavcodec/libavcodec.a(mpegvideo.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(h263.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(jrevdct.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here libavcodec/libavcodec.a(jfdctfst.o): In function `lrintf': /home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: multiple definition of `lrintf' libavcodec/libavcodec.a(utils.o):/home/ndeb/APPLICATIONS/movie_player/mplayer/main/libavcodec/dsputil.h:277: first defined here
it seems that you're using mandrake.... which version? i'm using mandrake cooker and no problems her... bye, gabor -- gpg key at www.keyserver.net
Gabor, I am using mandrake-9.0 (gcc-3.2-1mdk, stock, not cooker). which cooker version r u using ? Also, I checked the ffmpeg CVS and the latest change in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ffmpeg/ffmpeg/libavcodec/dspu... (v1.38 is the latest) clearly shows that nothing yet has changed in dsputil.h between the time when I got the compile error and now. Since u could compile it on mandrake-9.0, I am interested in knowing ur compiler version. thanks - Nil
On Tue, Nov 05, 2002 at 12:53:39PM -0500, Nilmoni Deb wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
Gabor, I am using mandrake-9.0 (gcc-3.2-1mdk, stock, not cooker). which cooker version r u using ?
Also, I checked the ffmpeg CVS and the latest change in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ffmpeg/ffmpeg/libavcodec/dspu... (v1.38 is the latest) clearly shows that nothing yet has changed in dsputil.h between the time when I got the compile error and now. Since u could compile it on mandrake-9.0, I am interested in knowing ur compiler version.
I fixed it in mplayer's configure script. It now checks for the presence of lrintf in the system libm and defines HAVE_LRINTF if it's present, so that the duplicate function won't get declared in dsputil.h. Rich
Richard, Thanks for the info. This may explain why Gabor could compile it with gcc-3.2/mandrake-9.0 but I failed with the same combination. Nevertheless, whoever said that the compiler should not segfault was right on. I have reported the bug to mandrake. thanks - Nil ------------------------------------------------------------ On Tue, Nov 05, 2002 at 12:53:39PM -0500, Nilmoni Deb wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
Gabor, I am using mandrake-9.0 (gcc-3.2-1mdk, stock, not cooker). which cooker version r u using ?
Also, I checked the ffmpeg CVS and the latest change in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ffmpeg/ffmpeg/libavcodec/dspu...
(v1.38 is the latest) clearly shows that nothing yet has changed in dsputil.h between the time when I got the compile error and now. Since u could compile it on mandrake-9.0, I am interested in knowing ur compiler version.
I fixed it in mplayer's configure script. It now checks for the presence of lrintf in the system libm and defines HAVE_LRINTF if it's present, so that the duplicate function won't get declared in dsputil.h. Rich
On Tue, Nov 05, 2002 at 01:10:55AM -0500, Nilmoni Deb wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
I deleted the word "static" in line 277 of libavcodec/dsputil.h . That fixed the compile problem. But I have no idea if thats the correct fix.
Instead just remove the lrintf function from dsputil.h entirely. It's only there for broken systems that don't have an ANSI-compliant compiler. With ffmpeg it's disabled via the configure script for systems that already have lrintf, but mplayer's configure hasn't had that test added yet. If no one else beats me to it, I'll add it. Rich
On Tue, Nov 05, 2002 at 01:00:26AM -0500, Nilmoni Deb wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error:
gcc -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o utils.o utils.c In file included from utils.c:20: dsputil.h:277: warning: static declaration for `lrintf' follows non-static dsputil.h: In function `lrintf': dsputil.h:279: internal error: Segmentation fault Please submit a full bug report, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Buggy compiler, this means submit a full bug report to the gcc developers and/or your vendor, not mplayer list. Seeing below:
with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions.
you should probably send this to Mandrake and replace your broken version of gcc with a working one in the mean time. :) Rich
On Tue, 2002-11-05 at 07:18, D Richard Felker III wrote:
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error: with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions.
you should probably send this to Mandrake and replace your broken version of gcc with a working one in the mean time. :)
his gcc is a working one :-) i'm using mandrake here, and i've just compiled mplayer fresh from cvs. bye, gabor -- gpg key at www.keyserver.net
On Tuesday, 05 November 2002, gabor wrote:
On Tue, 2002-11-05 at 07:18, D Richard Felker III wrote:
Using gcc-3.2 on latest mplayer/ffmpeg cvs. Here's the error: with preprocessed source if appropriate. See <URL:https://qa.mandrakesoft.com/> for instructions.
you should probably send this to Mandrake and replace your broken version of gcc with a working one in the mean time. :)
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
i'm using mandrake here, and i've just compiled mplayer fresh from cvs.
It's been worked around in the meantime, probably. -- MPlayer RPMs maintainer: http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/ "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
On Tue, 2002-11-05 at 14:59, Dominik Mierzejewski wrote:
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
you mean that mandrake's gcc is broken? why are you so sure that it's not a problem with something else ( can you be sure that in the same circumstances a "standard" gcc3.2 won't segfault? )
i'm using mandrake here, and i've just compiled mplayer fresh from cvs.
It's been worked around in the meantime, probably.
sorry, but i don't understand you... you mean that when he compiled his version, it segfaulted, but after that time someone committed a patch to mplayer to workaround the problem in mandrake's gcc, and because of that now i can compile mplayer? because it's not true... i've been compiling mplayer-cvs for x months 1-2-3 times a week... there was problem only once when gcc3.2 had problems with some gcc parameters.... and we weren't able to watch wmv files... i don't want to offend anyone, i just want to understand what are you saying thanks, gabor -- listening to Paul Van Dyk & Judge Jules - Essential Mix 2001-6-16 gpg key at www.keyserver.net
gabor wrote:
On Tue, 2002-11-05 at 14:59, Dominik Mierzejewski wrote:
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
you mean that mandrake's gcc is broken? why are you so sure that it's not a problem with something else ( can you be sure that in the same circumstances a "standard" gcc3.2 won't segfault? )
i'm using mandrake here, and i've just compiled mplayer fresh from cvs.
It's been worked around in the meantime, probably.
sorry, but i don't understand you... you mean that when he compiled his version, it segfaulted, but after that time someone committed a patch to mplayer to workaround the problem in mandrake's gcc, and because of that now i can compile mplayer?
because it's not true... i've been compiling mplayer-cvs for x months 1-2-3 times a week... there was problem only once when gcc3.2 had problems with some gcc parameters.... and we weren't able to watch wmv files...
i don't want to offend anyone, i just want to understand what are you saying
thanks, gabor
Personally I use mandrake 9.0 with gcc 3.2 and I have no problem to compile daily CVS of mplayer with CVS of libavcodec. I do it regularly, and I had only one CVS that did not compile (30 or 31st of October I think) and it was not due to the compiler. Maybe another problem ? Eric
On Tuesday, 05 November 2002, gabor wrote:
On Tue, 2002-11-05 at 14:59, Dominik Mierzejewski wrote:
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
you mean that mandrake's gcc is broken?
I'm saying it might be.
why are you so sure that it's not a problem with something else ( can you be sure that in the same circumstances a "standard" gcc3.2 won't segfault? )
That's possible, too. But since MDK's gcc is patched by MDK developers, it becomes "their" compiler.
i'm using mandrake here, and i've just compiled mplayer fresh from cvs.
It's been worked around in the meantime, probably.
sorry, but i don't understand you... you mean that when he compiled his version, it segfaulted, but after that time someone committed a patch to mplayer to workaround the problem in mandrake's gcc, and because of that now i can compile mplayer?
Yes, I meant that.
because it's not true... i've been compiling mplayer-cvs for x months 1-2-3 times a week... there was problem only once when gcc3.2 had problems with some gcc parameters.... and we weren't able to watch wmv files...
Well, I've had one case of a bug in gcc-3.1 from RH, which was worked around in a day or so by ffmpeg developers and fixed in RH (after I submitted a report in RH's bugzilla). So I can easily imagine that something similar may have happened this time. Even if it's not the case.
i don't want to offend anyone, i just want to understand what are you saying
No offence taken. :-) It's just that I think the compiler shouldn't segfault while compiling *any* code. PS. Where can I get your public PGP key? -- MPlayer RPMs maintainer: http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/ "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
On Tue, Nov 05, 2002 at 03:28:43PM +0100, gabor wrote:
On Tue, 2002-11-05 at 14:59, Dominik Mierzejewski wrote:
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
you mean that mandrake's gcc is broken? why are you so sure that it's not a problem with something else ( can you be sure that in the same circumstances a "standard" gcc3.2 won't segfault? )
If "standard" gcc 3.2 segfaults then it's also broken. gcc should never segault. Of course it wouldn't surprise me one bit if 3.x segfaults -- it's slow at compiling, generates slow code, and just seems broken in general. Rich
On Tue, 2002-11-05 at 18:18, D Richard Felker III wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] On Tue, Nov 05, 2002 at 03:28:43PM +0100, gabor wrote:
On Tue, 2002-11-05 at 14:59, Dominik Mierzejewski wrote:
his gcc is a working one :-)
I wouldn't call a compiler that segfaults a working one.
you mean that mandrake's gcc is broken? why are you so sure that it's not a problem with something else ( can you be sure that in the same circumstances a "standard" gcc3.2 won't segfault? )
If "standard" gcc 3.2 segfaults then it's also broken. gcc should never segault. Of course it wouldn't surprise me one bit if 3.x segfaults -- it's slow at compiling, generates slow code, and just seems broken in general.
it may be that 2.95.x ( 2.95.4 is the latest? ) is more polished/tested... but gcc3.x has better ansi-c++ support.... so for some c++ projects you don't have a choice.... this is not the case with mplayer of course :-) bye, gabor
Rich
_______________________________________________ RTFM!!! http://www.MPlayerHQ.hu/DOCS Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch http://mplayerhq.hu/mailman/listinfo/mplayer-users
-- gpg key at www.keyserver.net, wwwkeys.eu.pgp.net
gabor wrote:
you should probably send this to Mandrake and replace your broken version of gcc with a working one in the mean time. :) his gcc is a working one :-) Apparently not :)
gcc 3.2 couldn't even compile itself for me, it died with internal compiler error :PP (probably because I don't have "bleeding edge" glibc...) -- Gabucino
On Tuesday 05 November 2002 14.28, Gabucino wrote:
gabor wrote:
you should probably send this to Mandrake and replace your broken version of gcc with a working one in the mean time. :)
his gcc is a working one :-)
Apparently not :)
gcc 3.2 couldn't even compile itself for me, it died with internal compiler error :PP (probably because I don't have "bleeding edge" glibc...)
Probably, I've been using 3.2 for months (since gentoo 1.4_beta was released). And I haven't had a single problem yet. //David Holm
participants (7)
-
D Richard Felker III -
David Holm -
Dominik Mierzejewski -
Eric Fernandez -
gabor -
Gabucino -
Nilmoni Deb