That's a link step, so the compiler options are not going to help there.
But you might (a) Google for all these messages, (b) check the wikis and (c) trawl through any posts to this list. As I remember I had the same R_X86_64_32S error a few weeks ago. I think I got around it by using the external ffmpeg. On 27/04/07, Graham Evans <[EMAIL PROTECTED]> wrote:
> just wanted to point out: the problem of some objects to be liked dynamically > but not beeing built with -fPIC is the most common source of build problems > on x86_64. I learned to look at this first when problems pop up: are really > all (note all) parts to be linked in built with -fPIC ?? > > I think this is a very likely cause of the build failures (after having exhausted many other possible causes). I wonder where to go looking in terms of downgrading or build my own packages. The external ffmpeg on sid list the following dependencies: libavcodeccvs51 libavformatcvs51 libavutilcvs49 libc6 libfreetype6 libimlib2 libsdl1.2debian libswscalecvs0 I guess the internal ffmpeg relies on some of these progs too. This is another line of re > This is the important part. I.e. you should verify in the output of the make > command, that you find this sequence of flags really in the generated command > invocations somewhere (of courese there are some additional flags and there is the list > of libs to include and the path to the source to compile -- but you should find your > flags literally in every gcc or g++ invocation. This means esp. that in *every* > invocation there is a -fPIC at some point (and no -fpic) > > I'm learning huge amounts from this exercise - one small step closer to being able to hack on cinelerra! ...but building it would be a good start : p > But the problem is allways in the included ffmpeg directory? > > my problem is in building from the quicktime directory when the link is made to something in the ffmpeg/libavcodec directory. This problem: >> When I tried these flags after descending into quicktime or ffmpeg >> directories this caused the build to abort quickly with: >> gcc: cannot specify -o with -c or -S with multiple files >> >> occurs everywhere in the build tree if I use the CFLAGS you specified. Deleting the stray '-' > Then you could hand edit the Makefile just in the FFMPEG directory > to insert the right CFLAGS and CXXFLAGS (of cours this hand edits > are lost as soon as you re-invoke ./configure). > > yes tried that: *poured over the build output tracking back from the breakpoint to refferred packages and then back again from them. *made some mini Makefiles of my own, fiddling with -prefer-non-pic flags (ie deleted them) when building in the libavcodec/386/ directory *tried deleting DUSE_MMX flags when building in the libavcodec after reading a bit on this thread: >On Friday 26 January 2007 09:58, Alexis Ballier wrote..(some stuff about mmx flags sent to ffmpeg with x86_64 builds...) *mostly just confirmed that the CFLAGS and the -fPIC flags seemed to be passed on okay. None of this worked. or changed the final result. Although I've definitely added to my repetoir of techniques. some other stray details: Building with your flags causes the build to break at a slightly different point: .../usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): could not read symbols: Bad value... rather than .../usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.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(cputest.o): could not read symbols: Bad value ... Also - the only gcc command not to use the CFLAGS (like -fPIC) which I could find was the one which the program broke on: gcc -shared .libs/atom.o .libs/avcc.o .libs/avi_hdrl.o .libs/avi_idx1.o .libs/avi_movi.o .libs/avi_strl.o .libs/avi_odml.o .libs/avi_ix.o .libs/avi_indx.o .libs/avi_riff.o .libs/cmodel_default.o .libs/cmodel_float.o .libs/cmodel_yuv420p.o .libs/cmodel_yuv422.o .libs/codecs.o .libs/colormodels.o .libs/ctab.o .libs/dinf.o .libs/dref.o .libs/edts.o .libs/elst.o .libs/esds.o .libs/graphics.o .libs/hdlr.o .libs/ima4.o .libs/interlacemodes.o .libs/jpeg.o .libs/libdv.o .libs/libmjpeg.o .libs/matrix.o .libs/mdat.o .libs/mdhd.o .libs/mdia.o .libs/minf.o .libs/moov.o .libs/mp4a.o .libs/mvhd.o .libs/plugin.o .libs/qtcache.o .libs/qtdv.o .libs/qtffmpeg.o .libs/qth264.o .libs/qtpng.o .libs/qtmp3.o .libs/quicktime.o .libs/raw.o .libs/rawaudio.o .libs/rle.o .libs/smhd.o .libs/stbl.o .libs/stco.o .libs/stsc.o .libs/stsd.o .libs/stsdtable.o .libs/stss.o .libs/stsz.o .libs/stts.o .libs/tkhd.o .libs/trak.o .libs/twos.o .libs/udta.o .libs/ulaw.o .libs/util.o .libs/v308.o .libs/v408.o .libs/v410.o .libs/vmhd.o .libs/vbraudio.o .libs/vorbis.o .libs/workarounds.o .libs/yuv2.o .libs/yuv4.o .libs/yv12.o .libs/wmx2.o .libs/wma.o .libs/mpeg4.o -Wl,--whole-archive ffmpeg/libavcodec/.libs/libavcodec.a encore50/.libs/libencore.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/home/gray/install/hvirtual/libmpeg3/.libs /usr/lib/liba52.so -L/usr/lib /usr/lib/libvorbisenc.so /usr/lib/libvorbisfile.so /usr/lib/libvorbis.so /usr/lib/libtheora.so /usr/lib/libogg.so /usr/lib/libmp3lame.so /usr/lib/libfaad.so /usr/lib/libfaac.so ../libmpeg3/.libs/libmpeg3hv.so -lx264 /usr/lib/libdv.so /usr/lib/libjpeg.so -lpng -lz -lm -ldl -lpthread -msse3 -march=athlon64 -minline-all-stringops -Wl,--no-undefined -Wl,-soname -Wl,libquicktimehv-1.6.0.so.1 -o .libs/libquicktimehv-1.6.0.so.1.0.0 But inserting the flags (before the -o) made no difference. Somehow I think that wasn't the problem anyway. So - back to thinking about the cinelerra dependencies for now with libavcodec as a prime suspect... Thanks for the fantastic help. Graham _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
-- Regards, Martin ([EMAIL PROTECTED])