Martin Ellison wrote:
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.
Believe me - google, wiki and trawl is my modus operandi. And I have
discovered all the previous information relating to these problems which
HAVE arisen before. This suggests the problem may be with a new build
of a package which cinelerra relies on - and this is my current line of
investigation.
I have confirmed the external ffmpeg definitely bypasses these
problems. But it has others:
There is a bug filed on using the current ffmpeg with cinelerra. It is
probably a stretch to call it a bug as this is the reason cinelerra
relies on internal ffmpeg - the api for ffmpeg has changed. It might be
easier for me to learn how to patch cinelerra to call using the new
swscale methods than to keep hammering away at this build. But actually
that would be a whole new learning curve.
Even using the oldest ffmpeg available on etch repositories (august
2006) produces this problem. I'm worried if I go back to a sarge ffmpeg
I will start to break my other multimedia packages.
I could try downgrading ffmpeg and linking against it however...
Graham
On 27/04/07, *Graham Evans* <[EMAIL PROTECTED]
<mailto:[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 <mailto:Cinelerra@skolelinux.no>
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
--
Regards,
Martin
([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
