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])

Reply via email to