Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On 2007-08-22 05:04, Graham Evans wrote: > > > > > make[1]: Leaving directory `/home/gray/install/hvirtual' > > make: *** [all] Error 2 > > [EMAIL PROTECTED]:~/install/hvirtual$ > > > > I tested svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 smp > > with nvidia opengl driver. > > > Kevin > > Please ignore my message for now. I'm not sure what's wrong but I'm > getting this same build error for svn 1017 as well at present. I must > have messed something up. I will do a clean svn upload and try again. > That could take a while on dial up. > > Graham No problem Graham. I would have said this is a different problem anyway. :) You should not need to re-download svn trees. Have you tried 'svn diff > logfile' from your top level directory (trunk/hvirtual?) You can then look > at logfile to see if there are any local changes that might break the build. It may also be that you need to re-generate the top level configure file after my change (I modified configure.in.) I normally running 'autoreconf -if' to do that. If you use autogen.sh, that should work also. You will need to run configure again also. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 [EMAIL PROTECTED]:~/install/hvirtual$ I tested svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 smp with nvidia opengl driver. Kevin Please ignore my message for now. I'm not sure what's wrong but I'm getting this same build error for svn 1017 as well at present. I must have messed something up. I will do a clean svn upload and try again. That could take a while on dial up. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Kevin Brosius wrote: Well, this has been a long and somewhat painful investigation. :) I can answer why the original patch is not or should not be committed as is, Graham. It breaks 32 bit intel/amd platform builds. I've extended it and will commit a change that should work on all intel/amd 32 and 64 bit systems. Please let me know if anyone sees trouble with builds afterwards. Thanks to all for the feedback and build logs. It was nice to use some of those new build skills Hermann taught me a little while back. Next in my quest to hack on cinelerra is probably to learn some C++ . Anyway thanks Kevin for getting to the bottom of this but I still have a problem: /bin/sh ../libtool --tag=CC --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -o libmpeg2enc.la conform.lo mpeg2enc.lo putseq.lo putpic.lo puthdr.lo putmpg.lo putvlc.lo putbits.lo predict.lo readpic.lo writepic.lo transfrm.lo fdctref.lo idct.lo quantize.lo ratectl.lo stats.lo motion.lo cpu_accel.lo fdct_mmx.lo fdctdata.lo idct_mmx.lo idctdata.lo quant_mmx.lo quantize_x86.lo predict_mmx.lo predcomp_mmxe.lo predcomp_mmx.lo -lm -ldl -lpthread ar cru .libs/libmpeg2enc.a .libs/conform.o .libs/mpeg2enc.o .libs/putseq.o .libs/putpic.o .libs/puthdr.o .libs/putmpg.o .libs/putvlc.o .libs/putbits.o .libs/predict.o .libs/readpic.o .libs/writepic.o .libs/transfrm.o .libs/fdctref.o .libs/idct.o .libs/quantize.o .libs/ratectl.o .libs/stats.o .libs/motion.o .libs/cpu_accel.o .libs/fdct_mmx.o .libs/fdctdata.o .libs/idct_mmx.o .libs/idctdata.o .libs/quant_mmx.o .libs/quantize_x86.o .libs/predict_mmx.o .libs/predcomp_mmxe.o .libs/predcomp_mmx.o ar: .libs/fdct_mmx.o: No such file or directory make[2]: *** [libmpeg2enc.la] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 [EMAIL PROTECTED]:~/install/hvirtual$ I tested svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 smp with nvidia opengl driver. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On 2007-08-19 18:41, Kevin Brosius wrote: > On 2007-08-19 10:50, Graham Evans wrote: > > > > > > > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation > > > R_X86_64_32 against `a local symbol' can not be used when making a > > > shared object; recompile with -fPIC > > > > > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read > > > symbols: Bad value > > > > > > did not look into it but must be a change after my patch from earlier > > > this year. > > > > > > j > > > > > I'm pretty sure I can help with this one - by reposting a patch posted > > earlier by Hermann (easier than tracking down and constructing a useful > > link). > > > > Around the time of cinelerra svn 1000 I switched from fedora to debian > > sid and couldn't compile cinelerra anymore. My distro is debian sid > > pure 64 on an amd64smp/openGL system. I was having all sorts of fpic > > and ffmpeg problems exactly like the one above. Hermann had a patch > > which only changed one line in a makefile and that fixed all my > > problems. It looks like this patch has not been committed. Perhaps it > > will help you (attached). > > > > I'm not sure why this patch is not committed - perhaps there is some > > uncertainty whether it is sound for all build systems. > > > > With this patch I have been building all recent svn versions up to svn > > 1017 without any compile flags. > > > > best of luck and please send in any feedback which might help this patch > > get evaluated. > > Thanks Graham, > > I suspect no one knew the full impact of this change. > > I think it will fix my build problem also. > > Does anyone have a system that builds without -fPIC on a 64 bit platform > (either amd64 or Intel?) I think that is the only case that may break > with the change. I don't see any results for this case, although there > are some comments that fPIC should not be needed in all cases. > Well, this has been a long and somewhat painful investigation. :) I can answer why the original patch is not or should not be committed as is, Graham. It breaks 32 bit intel/amd platform builds. I've extended it and will commit a change that should work on all intel/amd 32 and 64 bit systems. Please let me know if anyone sees trouble with builds afterwards. The short version, is that ffmpeg/libavcodec in our tree needs -prefer-non-pic for 32 bit platforms, but not 64 bit (on the platforms I tested and for the people who reported in this thread.) If you disable PIC completely on 64 bit platforms, you will normally fail to link, either the ffmpeg portion or a higher level library. On 32bit, it's a little more complicated. ffmpeg/avcodec builds with PIC, but selectively. The mpegvideo_mmx file can not build with PIC, else it will not have enough registers to compile successfully. The -prefer-non-pic causes ffmpeg to build some files with PIC and some without, mpegvideo_mmx being built without PIC. I suspect you can break the build by overriding all this with one of --with-pic or --without-pic on the top level configure. Thanks to all for the feedback and build logs. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On 2007-08-19 10:50, Graham Evans wrote: > > > > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation > > R_X86_64_32 against `a local symbol' can not be used when making a > > shared object; recompile with -fPIC > > > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read > > symbols: Bad value > > > > did not look into it but must be a change after my patch from earlier > > this year. > > > > j > > > I'm pretty sure I can help with this one - by reposting a patch posted > earlier by Hermann (easier than tracking down and constructing a useful > link). > > Around the time of cinelerra svn 1000 I switched from fedora to debian > sid and couldn't compile cinelerra anymore. My distro is debian sid > pure 64 on an amd64smp/openGL system. I was having all sorts of fpic > and ffmpeg problems exactly like the one above. Hermann had a patch > which only changed one line in a makefile and that fixed all my > problems. It looks like this patch has not been committed. Perhaps it > will help you (attached). > > I'm not sure why this patch is not committed - perhaps there is some > uncertainty whether it is sound for all build systems. > > With this patch I have been building all recent svn versions up to svn > 1017 without any compile flags. > > best of luck and please send in any feedback which might help this patch > get evaluated. Thanks Graham, I suspect no one knew the full impact of this change. I think it will fix my build problem also. Does anyone have a system that builds without -fPIC on a 64 bit platform (either amd64 or Intel?) I think that is the only case that may break with the change. I don't see any results for this case, although there are some comments that fPIC should not be needed in all cases. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
I was running into the same error, until I disabled mmx. I finally was able to compile Cinelerra with AMD64 ubuntu, for the first time ever, before I always had to muddy up my repositories with stuff from Debian unstable that made upgrading a pain and installing certain software from repositories difficult. Does anyone know if MMX optimizations will make enough of a performance difference that I should try recompiling with the fix. I will check my logs to see if I used --with-pic, I think that I did. > for what its worth > svn up && ./autogen.sh && ./configure --enable-mmx --with-pic && make > does *not* work on my amd 64 / ubuntu box right now. > > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation > R_X86_64_32 against `a local symbol' can not be used when making a > shared object; recompile with -fPIC > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read > symbols: Bad value > > did not look into it but must be a change after my patch from earlier > this year. > > j > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On Aug 19, 2007, at 14:30:25, Kevin Brosius wrote: Does removing both --enable-mmx and --with-pic build for you? Does it auto detect mmx and build with it anyway in that case? trying again with just "./configure" mmx is enabled, build fails with fmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read symbols: Bad value I noticed from your older emails, j, that you were not using internal ffmpeg. I think that is why this was not noticed before. If the build was using external ffmpeg, then I would not expect to see the error you posted. right, bundled ffmpeg never worked for me on 64bit - keep forgetting that... Also, if you have a build log, would you show me the compile options of mpegvideo_mmx when it builds? (If it builds... It will only build if mmx is specified or auto detected as true. I'd like to know if it does not auto detect mmx also.) gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -D_LARGEFILE_SOURCE - D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX - DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE - DHAVE_AV_CONFIG_H -I./../.. -I../.. -g -O2 -MT mpegvideo_mmx.lo -MD - MP -MF .deps/mpegvideo_mmx.Tpo -c mpegvideo_mmx.c -o .libs/ mpegvideo_mmx.o j ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Well, I think the trouble here is that either ffmpeg should follow the PIC behavior of the rest of the build, or is broken for PIC in general. I saw a note that debian policy required build with PIC for a time. I don't think that will continue, as present comments say PIC should not be required. I do see PIC used in the general Cin portion of the build here on Suse. Do you know, or can you check, if PIC was used in your builds of the main portion of Cin, Graham? Hi Kevin Let me know if I have gone wrong but I think I have the neccessary skills to answer your questions. Note all the following tests are performed on cinelerra CV svn 1017 with Hermann's patch as attached to my last email. This builds and runs succesfully and performs well as far as I can see. Firstly - I am guessing this is a typical gcc command for cinelerra: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./.. -DHAVE_MMX -DUSE_MMX -DX86_CPU -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -MT idct.lo -MD -MP -MF .deps/idct.Tpo -c idct.c -fPIC -DPIC -o .libs/idct.o I'm not sure if that includes the PIC flag you were looking for. Also, if you have a build log, would you show me the compile options of mpegvideo_mmx when it builds? (If it builds... It will only build if mmx is specified or auto detected as true. I'd like to know if it does not auto detect mmx also.) MMX is detected I suppose from this: 'CPU_CFLAGS='-DHAVE_MMX -DUSE_MMX -DX86_CPU ' Compile options for mpegvideo_mmx: if /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../../..-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -I../.. -g -O2 -MT mpegvideo_mmx.lo -MD -MP -MF ".deps/mpegvideo_mmx.Tpo" -c -o mpegvideo_mmx.lo mpegvideo_mmx.c; \ then mv -f ".deps/mpegvideo_mmx.Tpo" ".deps/mpegvideo_mmx.Plo"; else rm -f ".deps/mpegvideo_mmx.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -I../.. -g -O2 -MT mpegvideo_mmx.lo -MD -MP -MF .deps/mpegvideo_mmx.Tpo -c mpegvideo_mmx.c -fPIC -DPIC -o .libs/mpegvideo_mmx.o Thanks all, And a quick comment about ffmpeg external option - my understanding is that ffmpeg versions since about August 2006 are incompatible with the current cinelerra. There is already a bug filed about that. I think the recommended way to build cinelerra at present is to somehow get internal ffmpeg working. On debian etch + going to a version of ffmpeg early enough to get a successful build breaks dependencies in lots of unrelated deb packages. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On 2007-08-19 09:04, j wrote: > for what its worth > svn up && ./autogen.sh && ./configure --enable-mmx --with-pic && make > does *not* work on my amd 64 / ubuntu box right now. > No, probably not, but I think that's ok. --with-pic is kind of ugly. You can build if that option is not specified, right? Does removing both --enable-mmx and --with-pic build for you? Does it auto detect mmx and build with it anyway in that case? > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation > R_X86_64_32 against `a local symbol' can not be used when making a > shared object; recompile with -fPIC > > ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read > symbols: Bad value > > did not look into it but must be a change after my patch from earlier > this year. This it the error I see, but it's because ffmpeg does not build with PIC, even though the rest of the build does. An additional problem may be that there was trouble building the mmx portion of ffmpeg some time ago with PIC. I need to verify of that is why we've had so much trouble with it. I noticed from your older emails, j, that you were not using internal ffmpeg. I think that is why this was not noticed before. If the build was using external ffmpeg, then I would not expect to see the error you posted. On 2007-08-19 10:50, Graham Evans wrote: ... > Around the time of cinelerra svn 1000 I switched from fedora to debian > sid and couldn't compile cinelerra anymore. My distro is debian sid > pure 64 on an amd64smp/openGL system. I was having all sorts of fpic > and ffmpeg problems exactly like the one above. Hermann had a patch > which only changed one line in a makefile and that fixed all my > problems. It looks like this patch has not been committed. Perhaps it > will help you (attached). > > I'm not sure why this patch is not committed - perhaps there is some > uncertainty whether it is sound for all build systems. Well, I think the trouble here is that either ffmpeg should follow the PIC behavior of the rest of the build, or is broken for PIC in general. I saw a note that debian policy required build with PIC for a time. I don't think that will continue, as present comments say PIC should not be required. I do see PIC used in the general Cin portion of the build here on Suse. Do you know, or can you check, if PIC was used in your builds of the main portion of Cin, Graham? Also, if you have a build log, would you show me the compile options of mpegvideo_mmx when it builds? (If it builds... It will only build if mmx is specified or auto detected as true. I'd like to know if it does not auto detect mmx also.) Thanks all, -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read symbols: Bad value did not look into it but must be a change after my patch from earlier this year. j I'm pretty sure I can help with this one - by reposting a patch posted earlier by Hermann (easier than tracking down and constructing a useful link). Around the time of cinelerra svn 1000 I switched from fedora to debian sid and couldn't compile cinelerra anymore. My distro is debian sid pure 64 on an amd64smp/openGL system. I was having all sorts of fpic and ffmpeg problems exactly like the one above. Hermann had a patch which only changed one line in a makefile and that fixed all my problems. It looks like this patch has not been committed. Perhaps it will help you (attached). I'm not sure why this patch is not committed - perhaps there is some uncertainty whether it is sound for all build systems. With this patch I have been building all recent svn versions up to svn 1017 without any compile flags. best of luck and please send in any feedback which might help this patch get evaluated. Graham --- a/quicktime/ffmpeg/libavcodec/i386/Makefile.am +++ b/quicktime/ffmpeg/libavcodec/i386/Makefile.am @@ -12,7 +12,7 @@ AM_CFLAGS = \ $(LARGEFILE_CFLAGS) \ $(CPU_CFLAGS) \ -DHAVE_MMX $(SSE_FLAGS) \ - -O3 -prefer-non-pic \ + -O3 \ -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I$(srcdir)/../.. -I../.. libavcodeci386_la_SOURCES = \
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
for what its worth svn up && ./autogen.sh && ./configure --enable-mmx --with-pic && make does *not* work on my amd 64 / ubuntu box right now. ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read symbols: Bad value did not look into it but must be a change after my patch from earlier this year. j ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On Aug 18, 2007, at 22:35:43, Johannes Sixt wrote: Do you recall what platform j was using? I assume the patch fixed the build on his platform while breaking SUSE. Sorry, I can't remember the details, not even my own arguments. Please search in ML archives. I'd appreciate if you could go over this issue again. I don't have the hardware to help. Let's hope that j is listening and can give feedback. that was on debian/etch and ubuntu/feisty amd64 the problem is/was that the mmx code in libmpeg3 is 32bit only, while ffmepg has working 64bit mmx code. j ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On Saturday 18 August 2007 21:19, Kevin Brosius wrote: > Johannes Sixt wrote: > > On Saturday 18 August 2007 03:35, Kevin Brosius wrote: > > > While this addresses libmpeg3, there are also uses of USEMMX in > > > quicktime/ffmpeg/libavcodec > > > > The purpose of this fix, AFAIR, was to address only MMX issues in > > libmpeg3, not in ffmpeg. I faintly recall that I have even encouraged j > > not to touch USEMMX in ffmpeg, because it has a different meaning/purpose > > there. What's your problem? > > I suspect it is that MMX is now enabled in ffpmeg where it was not > before, and fPIC is not set properly for the ffpmeg build. I am seeing > an fPIC error while trying to link mpegvideo_mmx.o in > ffmpeg/libavcodec. The failure is because the mmx .o file is built > without -fPIC. > > Note that the patch adds a x86_64 cpu target to configure.in which auto > detects mmx, it seems. This enables mmx for all sublibs on x86_64, > which was not the case before. There is a new USEMMX32 define for > non-64 bit targets... Also, the configure for 3dnow was left off the > x86_64 arch block in configure.in, was this intentional? > > Anyway, we should be able to enable mmx across the board on x86_64, I > would think. I'll look in to why ffmpeg doesn't configure the same as > other parts of the build with respect to -fPIC. I noticed there was a > change to it's -fPIC preference also. This may relate to the trouble. > > Do you recall what platform j was using? I assume the patch fixed the > build on his platform while breaking SUSE. Sorry, I can't remember the details, not even my own arguments. Please search in ML archives. I'd appreciate if you could go over this issue again. I don't have the hardware to help. Let's hope that j is listening and can give feedback. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Johannes Sixt wrote: > > > On Saturday 18 August 2007 03:35, Kevin Brosius wrote: > > Should have sent this to devel... > > > > I've run into build trouble on SUSE x86_64 related to this patch: > > > > On 2007-03-31 19:36, Johannes Sixt <[EMAIL PROTECTED]> wrote: > > > Author: j6t > > > Date: 2007-03-31 21:36:53 +0200 (Sat, 31 Mar 2007) > > > New Revision: 1007 > > > > > > Modified: > > >trunk/hvirtual/configure.in > > >trunk/hvirtual/libmpeg3/video/Makefile.am > > > Log: > > > Make configure detect and work on amd64. > > > > > > Patch by j <[EMAIL PROTECTED]>. > > > > Hannes, or j, > > > > The use of USEMMX is not just in libmpeg3, which was changed. > > > > > AM_CONDITIONAL(USEMMX, test "x$enable_mmx" = "xyes") > > > +AM_CONDITIONAL(USEMMX32, test "x$enable_mmx32" = "xyes") > > > > While this addresses libmpeg3, there are also uses of USEMMX in > > quicktime/ffmpeg/libavcodec > > The purpose of this fix, AFAIR, was to address only MMX issues in libmpeg3, > not in ffmpeg. I faintly recall that I have even encouraged j not to touch > USEMMX in ffmpeg, because it has a different meaning/purpose there. What's > your problem? I suspect it is that MMX is now enabled in ffpmeg where it was not before, and fPIC is not set properly for the ffpmeg build. I am seeing an fPIC error while trying to link mpegvideo_mmx.o in ffmpeg/libavcodec. The failure is because the mmx .o file is built without -fPIC. Note that the patch adds a x86_64 cpu target to configure.in which auto detects mmx, it seems. This enables mmx for all sublibs on x86_64, which was not the case before. There is a new USEMMX32 define for non-64 bit targets... Also, the configure for 3dnow was left off the x86_64 arch block in configure.in, was this intentional? Anyway, we should be able to enable mmx across the board on x86_64, I would think. I'll look in to why ffmpeg doesn't configure the same as other parts of the build with respect to -fPIC. I noticed there was a change to it's -fPIC preference also. This may relate to the trouble. Do you recall what platform j was using? I assume the patch fixed the build on his platform while breaking SUSE. I can build if I pass --disable-mmx to configure, skipping the trouble files in ffmpeg. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On Saturday 18 August 2007 03:35, Kevin Brosius wrote: > Should have sent this to devel... > > I've run into build trouble on SUSE x86_64 related to this patch: > > On 2007-03-31 19:36, Johannes Sixt <[EMAIL PROTECTED]> wrote: > > Author: j6t > > Date: 2007-03-31 21:36:53 +0200 (Sat, 31 Mar 2007) > > New Revision: 1007 > > > > Modified: > >trunk/hvirtual/configure.in > >trunk/hvirtual/libmpeg3/video/Makefile.am > > Log: > > Make configure detect and work on amd64. > > > > Patch by j <[EMAIL PROTECTED]>. > > Hannes, or j, > > The use of USEMMX is not just in libmpeg3, which was changed. > > > AM_CONDITIONAL(USEMMX, test "x$enable_mmx" = "xyes") > > +AM_CONDITIONAL(USEMMX32, test "x$enable_mmx32" = "xyes") > > While this addresses libmpeg3, there are also uses of USEMMX in > quicktime/ffmpeg/libavcodec The purpose of this fix, AFAIR, was to address only MMX issues in libmpeg3, not in ffmpeg. I faintly recall that I have even encouraged j not to touch USEMMX in ffmpeg, because it has a different meaning/purpose there. What's your problem? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Should have sent this to devel... I've run into build trouble on SUSE x86_64 related to this patch: On 2007-03-31 19:36, Johannes Sixt <[EMAIL PROTECTED]> wrote: > Author: j6t > Date: 2007-03-31 21:36:53 +0200 (Sat, 31 Mar 2007) > New Revision: 1007 > > Modified: >trunk/hvirtual/configure.in >trunk/hvirtual/libmpeg3/video/Makefile.am > Log: > Make configure detect and work on amd64. > > Patch by j <[EMAIL PROTECTED]>. > Hannes, or j, The use of USEMMX is not just in libmpeg3, which was changed. > > AM_CONDITIONAL(USEMMX, test "x$enable_mmx" = "xyes") > +AM_CONDITIONAL(USEMMX32, test "x$enable_mmx32" = "xyes") While this addresses libmpeg3, there are also uses of USEMMX in quicktime/ffmpeg/libavcodec > Modified: trunk/hvirtual/libmpeg3/video/Makefile.am > === > --- trunk/hvirtual/libmpeg3/video/Makefile.am2007-03-05 19:49:17 UTC (rev > 1006) > +++ trunk/hvirtual/libmpeg3/video/Makefile.am2007-03-31 19:36:53 UTC (rev > 1007) > @@ -9,7 +9,7 @@ > subtitle.c \ > vlc.c > > -if USEMMX > +if USEMMX32 > libmpeg3_video_la_SOURCES += mmxidct.S reconmmx.s > else > libmpeg3_video_la_SOURCES += What was the intention of USEMMX vs. USEMMX32? Would you expect to need to disable mmx in ffmpeg also? Thanks, -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
