Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

$ make -k CFLAGS='-O0 -g'
# this errors out in fdct_mmx.c with "operands invalid for `pshufw'"
$ rm quicktime/ffmpeg/libavcodec/i386/fdct_mmx.*o
$ make CFLAGS='-O2 -g'

(It seems that this file wants to be compiled with some different sort of 
optimization.)


BTW, I just noticed that the build flags of quicktime/ffmpeg/libavcodec/i386/ 
include -O3. Try removing that from Makefile.am - it is needed on i*86, but 
may not be needed on x86_64.


-- Hannes

  

A successful build - finally...thank you Hannes.
As they say in Experts exchange or wherever - you win the prize...

I'm not clear yet on where the build was going wrong but most definitely 
in the quicktime/ffmpeg/libavcodec/i386 directory.


I decided to try with the latest automake (1.10) and my eventual success 
suggests the debian build comments in the autogen.sh script now need to 
be deleted (they say to use automake 1.7).


Another discovery : I came across references in makefiles to previously 
used automake versions.  I manually purged a lot of hvirtual directory 
files to overcome this.  So perhaps the autogen.sh script does not clean 
out all the old files properly.  Some of these maybe: depcomp, libtool, 
ltmain.sh, mkinstalldirs...


I started with a no flags: ./configure
then: make
once it broke I used: make -k 'O0 -g'
make (to remind me where breakages were still happening)
rm quicktime/ffmpeg/libavcodec/i386/..[broken lib].*o
fiddled with the Makefile in quicktime/ffmpeg/libavcodec/i386/
and used either
make CFLAGS='-O3 -g'
CFLAGS='-O0 -g'
or: CFLAGS='-O2 -g'
until all the build errors were solved.
My final Makefile in the i386 directory had no -O3 optimisation, no 
-prefer-non-pic and included an -fPIC flag.


Until I discover exactly which steps were necessary my bug report is 
probably not useful - I will only submit one if someone here tells me 
it's a good idea.


Hopefully my skills will eventually allow me to make packages and submit 
patches.  But that could be quite a while away...


For now all I can do is say thanks everyone for all the help.  I'm happy 
to have my Cinelerra back!


Graham

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Herman Robak]

On Fri, 2007-04-27 at 13:06 -0300, rafael2k wrote:
> Hi all,
> 
> > BTW, to the best of my knowledge, dynamic linking does *not* require -fPIC!
> > It just so happens that if you compile with -fPIC then some amount of
> > memory can be saved if the dynamic object is shared by different processes.
> > Which is an unlikely situation for all dynamic objects that Cinelerra
> > loads. For this reason, I suggested to configure --without-pic.
> 
> AFAIK, for x86_64, "-fPIC" is really needed for shared libraries.

Quoting myself from the IRC-log:

"It turned out that libx264 had two .a files, one with "pic" 
in the name. The linker picked the other one, hence linking
failed.
That was fixed with a symlink (gross, I know)."

http://cv.cinelerra.org/irclog/index.php?file=2006-12-06.html

Could that be the problem?  Cinelerra simply would not link
until on my Opteron until I worked around that.

-- 
 Herman Robak


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Ichthyostega]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Graham Evans schrieb:
> very new to me.  Perhaps I will try rebuilding x264 and
> libavcodec(cvs51?) using the deb packages as my next step.

building on debian is much more easy then directly building some tarball.
You should start out with a simple package, e.g. bzip2
Just try to build the bzip2 package yourself!
apt-get source bzip2
...
...

see 
http://www.debian.de/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-sourcepkgs

The complications arise from all those multimedia libs, which are often
not in the standard repos or only available in certain versions, which
depend on other libs, which in turn conflict with the libs in you system,
so you some (careful) upgrades etc. This can get complicated, because
you should better restrain from upgrading the libc, the X-Server or
perl and python, just to get a package compiled :-)


> just one more note - I don't have a lib264_pic.a file - neither my own
> build of x264 nor the x264 deb package created this.  Did you name it
> yourself during your rebuild?

it was in the libx264-dev debian package, but I rechecked and it seems
to be gone with one of the last upgrades.

Cheers,
Hermann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGM6MYZbZrB6HelLIRAvr2AJ9ZxYLmh/l8L/m//fomYIIA2oRb+ACg4xWV
1sI87vQPcTBQ3Rd8qAj4R4Y=
=8KN5
-END PGP SIGNATURE-

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Johannes Sixt]

On Saturday 28 April 2007 14:07, Graham Evans wrote:
> > In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg
> > with different optimizations. Like:
> >
> > $ rm ffmpeg/libavcodec/cputest.*o
> > $ make CFLAGS='-O0 -g'
>
> okay tried all that.  Except I found deleting the files had no effect
> - they were just recreated each time.

that's the point - when they are recreated, then with the altered optimization 
flags.

From your message I assume that you got the same error. Then take the other 
route:

$ make -k CFLAGS='-O0 -g'
# this errors out in fdct_mmx.c with "operands invalid for `pshufw'"
$ rm quicktime/ffmpeg/libavcodec/i386/fdct_mmx.*o
$ make CFLAGS='-O2 -g'

(It seems that this file wants to be compiled with some different sort of 
optimization.)

BTW, I just noticed that the build flags of quicktime/ffmpeg/libavcodec/i386/ 
include -O3. Try removing that from Makefile.am - it is needed on i*86, but 
may not be needed on x86_64.

-- Hannes

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

Ichthyostega wrote:

actually, success in running can help a bit. Am I asuming right you are
trying to install on debian or ubuntu? Well, I'm more familiar with that
then with RPMs  :-)
  
I have just switched to debian etch-amd64(smp) (upon official release) 
from fedora core 4-64.  After about a week I decided to 'upgrade' to sid 
and that was when I decided it was time to get cinelerra working again...

If you want to investigate further on debian/ubuntu, the next step after
"successfully running" would be to re-compile the bin package you just
successfully installed. Ideally this would give you a working compile
(for further investigation different switches or for getting things
like opengl running).
  
okay - I will slowly begin to try such things out - I have lots to learn 
about deb packages so that should be fun..

Basically, the version in Cinelerra-SVN is a valid debian package. So it
could be feesible to take a diff between vale's package and the Cinelerra-SVN.
For this to work you would need the same SVN-revision which was used to create
vale's package.
  

ah. interesting!  Maybe I can do that...

Do you know the tools available for building on debian?  -- see below for sort
of a short version "how to build on debian". I'm attaching this just in case
it may be helpful.
  
very new to me.  Perhaps I will try rebuilding x264 and 
libavcodec(cvs51?) using the deb packages as my next step.

Further, I allways get a -fPIC problem with x264 and have to...
ln -s /usr/lib/libx264_pic.a /usr/lib/libx264.a
  
just one more note - I don't have a lib264_pic.a file - neither my own 
build of x264 nor the x264 deb package created this.  Did you name it 
yourself during your rebuild?


once again you've given me a way to move forward.
thank you
Graham

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Ichthyostega]

Graham,

...just to add one point: I don't know what the situation with building
cinelerra is exactly at the moment. I am in the middle of a larger movie
project and the last version I built was from last October -r 909.
I have my a patch for enhancing the bezier automation curves aplied
on top of this and just do recompiles of my own version from time to
time. I am on "64Studio", wich is very close to debian etch
(the one that just was released some weeks ago).

Hermann


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Ichthyostega]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Graham Evans schrieb:
> Hermann or someone else - perhaps you can help me here.
> 
> As a test I installed Vales debian x86_64 packages and that went without
> a hitch.  I think that means my external dependencies are okay... or
> not?  Perhaps building is one thing and executing a binary is another.
> 
> The pre-built packages are: cinelerra, libmpeg3hv and libquicktimehv
> 
> Does success in running the pre-build eliminates any of the things I
> need to look for in resolving my build problems?

Hi Graham,

actually, success in running can help a bit. Am I asuming right you are
trying to install on debian or ubuntu? Well, I'm more familiar with that
then with RPMs  :-)

Some random thoughts --

If you want to investigate further on debian/ubuntu, the next step after
"successfully running" would be to re-compile the bin package you just
successfully installed. Ideally this would give you a working compile
(for further investigation different switches or for getting things
like opengl running).

Basically, the version in Cinelerra-SVN is a valid debian package. So it
could be feesible to take a diff between vale's package and the Cinelerra-SVN.
For this to work you would need the same SVN-revision which was used to create
vale's package.
That's the way I am doing my Cinelerra hacking: Some time ago, I created
a patch containing all steps I needed to transform the current SVN into
a working debian package. Every time I when I load a new version, I apply
this patch and voila! I can build the current SVN als *.deb and install
it cleanly into my system. At times, I have even two differen versions
lying around, one built with -O3 (wich I use for real cutting) and
the same source code built with -O1 and -g to be used with gdm, so if
there is a bug (probably caused by my own hacking), i just switch over
to the "debug" with one dpkg -i command, reload the session which showed
the problem and attach gdm to the PID.


Do you know the tools available for building on debian?  -- see below for sort
of a short version "how to build on debian". I'm attaching this just in case
it may be helpful.

The point is: because building on debian is almost completely automatic, you
can always recompile for your specific system if only you can get hold of a
debian source package. In most cases it is worth the effort trying to find
a debian package instead of just using the upstream tarball of some library.
Some time ago I hat a -fPIC problem with some lib (I think it was libavcodec),
so I just grabbed the corresponding source, adapted the debian/rules to add
the -fPIC switch and recompiled a custom version for my system.

Some of the multimedia packages are not in the normal debian repos because
of patent issues (liblame, or lbavcodec, libfaac).
A good source is allways "debian-multimedia", http://debian-multimedia.org/
the former "debian marilat repo", which has several mirrors round the globe)

hopefully, some of this informations answer your question

Cheers,
Hermann


PS: In the "checkbuilddeps" phase there are often different problems depending
on the current verson of the libs. (collision between liblame0-dev und 
liblame-dev,
problems getting libavcodeccvs-dev.

Further, I allways get a -fPIC problem with x264 and have to...
ln -s /usr/lib/libx264_pic.a /usr/lib/libx264.a


 =

If you got your packages form a debian/ubuntu repository configured for apt
(or synaptic etc.), then you can just step into a new directory owned by
you, and type apt-get source PACKAGENAME
If you directly downloaded the packages (and installed them with dpkg -i),
then you should be able to find the corresponding source packages at the
same location (its a *.dsc file and a tar and maybe an additional patch
to debianize the tar).

you can just unpack the tar (and apply a patch if necessary) or use
dpkg-source -x .dsc

(Note, for building you may need to install packages "build-essential"
and "fakeroot" first)

then you step into the root of the source tree and run the command..

dpkg-checkbuilddeps

...to check for build-dependencies. This will point out all the -dev packages
you need to install in order do build. (Contrary to the bin packages, those
dev packages contain static libs to link against and/or header files; they
allways depend on the corresponding bin package of the exact same version
and it can be sometimes difficult to get both of the same version without
breaking other dependencies in the system. But in most cases, this just
works "magically").

You could even use APT to direcly install all dependencies

apt-get build-deb PACKAGENAME

After that you should be ready to build. Start the build with

dpkg-buildpackage -rfakeroot

helpfull additional swithes: -b :build only the binary package and
- -nc : "no clean", just recompile; usefull if you are hacking the source.
append " 2>&1 | tee proto.txt " to get the output of m

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg with 
different optimizations. Like:


$ rm ffmpeg/libavcodec/cputest.*o
$ make CFLAGS='-O0 -g'

  

okay tried all that.  Except I found deleting the files had no effect
- they were just recreated each time.  Instead I deleted makefile
references to these files.  All the references were in the makefile in
the directory:
quicktime/ffmpeg/libavcodec/i386/

If I configure and run with the complicated CFLAGS which Hermann
supplied I end up only needing to delete:
simple_idct_mmx.*
dsputil_mmx*.*
motion_est_mmx*.*

without Hermanns configuration, or with the Make CFLAGS='-O0 -f' i 
needed to delete those files plus also:

fdct_mmx.*
idct_mmx.*
dsputil_mmx*.*

all in that same makefile.

Anyway deleting these files finally causes a new type of build error
'undefined reference to mm flags'.  I didn't try to fix this one as I
assumed it was a problem created by my deletions (output snippet below
this email).

I'm seeing the pattern of problem libraries being associated with mmx.
I wonder if something is still broken in the auto configuration of mmx
flags for x86_64?  Or if this indicates any particular one of my 
dependencies as the problem.  Any more ideas on the topic?


Graham E.


ffmpeg/libavcodec/.libs/libavcodec.a(utils.o): In function
`avcodec_encode_video':
utils.c:(.text+0x139a): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(utils.o): In function
`avcodec_decode_video':
utils.c:(.text+0x14d4): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function
`MPV_frame_end':
mpegvideo.c:(.text+0x5cde): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function
`select_input_picture':
mpegvideo.c:(.text+0x8e11): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function
`ff_draw_horiz_band':
mpegvideo.c:(.text+0x195a9): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o):mpegvideo.c:(.text+0x1f90c): 


more undefined references to `mm_flags' follow
ffmpeg/libavcodec/.libs/libavcodec.a(dsputil.o): In function `dsputil_init':
dsputil.c:(.text+0x23a58): undefined reference to `dsputil_init_mmx'
ffmpeg/libavcodec/.libs/libavcodec.a(imgresample.o): In function
`h_resample':
imgresample.c:(.text+0x83d): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function
`slice_decode_thread':
mpeg12.c:(.text+0xa84d): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function
`mpeg_decode_frame':
mpeg12.c:(.text+0xbc30): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function `decode_frame':
mpeg12.c:(.text+0xc07e): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o): In function
`ff_rate_control_init':
ratecontrol.c:(.text+0x13d): undefined reference to `mm_flags'
ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o):ratecontrol.c:(.text+0xbf0): 


more undefined references to `mm_flags' follow
collect2: ld returned 1 exit status
make[1]: *** [libquicktimehv.la] Error 1
make[1]: Leaving directory `/home/gray/install/hvirtual/quicktime'
make: *** [all-recursive] Error 1






___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[rafael2k]

Hi all,

> BTW, to the best of my knowledge, dynamic linking does *not* require -fPIC!
> It just so happens that if you compile with -fPIC then some amount of
> memory can be saved if the dynamic object is shared by different processes.
> Which is an unlikely situation for all dynamic objects that Cinelerra
> loads. For this reason, I suggested to configure --without-pic.

AFAIK, for x86_64, "-fPIC" is really needed for shared libraries.

bye,
rafael diniz

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Eng. da Computação @  Unicamp
Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org
Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



pgpbZa11pshMp.pgp
Description: PGP signature

Re: [CinCVS] theme S.U.V. not found

[Johannes Sixt]

On Thursday 26 April 2007 08:10, Graham Evans wrote:
> /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
> collect2: ld returned 1 exit status

In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg with 
different optimizations. Like:

$ rm ffmpeg/libavcodec/cputest.*o
$ make CFLAGS='-O0 -g'

BTW, to the best of my knowledge, dynamic linking does *not* require -fPIC! It 
just so happens that if you compile with -fPIC then some amount of memory can 
be saved if the dynamic object is shared by different processes. Which is an 
unlikely situation for all dynamic objects that Cinelerra loads. For this 
reason, I suggested to configure --without-pic.

-- Hannes

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

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 ??

  

Hermann or someone else - perhaps you can help me here.

As a test I installed Vales debian x86_64 packages and that went without 
a hitch.  I think that means my external dependencies are okay... or 
not?  Perhaps building is one thing and executing a binary is another.


The pre-built packages are: cinelerra, libmpeg3hv and libquicktimehv

Does success in running the pre-build eliminates any of the things I 
need to look for in resolving my build problems?


Graham


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

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

Re: [CinCVS] theme S.U.V. not found

[Martin Ellison]

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.

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

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/li

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

I just noticed my configure output contains these lines:

config.status: creating po/Makefile.in
config.status: WARNING:  po/Makefile.in.in seems to ignore the 
--datarootdir setting


does anyone know if this is significant?

Graham E.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Ichthyostega]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Graham Evans schrieb:
> Hi Hermann
>> work. On debian, this is very common a problem with the libx264. So
>> they (DEBIAN,UBUNTU)
>> provide in their package both versions, one built with -fpic and one
>> built with -fPIC. 
>>   
> I've actually built a new x264 according to some instructions I found on
> a ubuntu forum.  I'm pretty sure I got that part right -also none of my
> errors seem to relate to x264 so far.

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 ??

>> CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops
>> -minline-all-stringops -fprefetch-loop-arrays -fPIC
>> CXXFLAGS=$(CFLAGS) -fno-check-new
>> CONFFLAGS+=--enable-sse3 --with-pic
>>
>>   
> This is excellent detail thank you.  I've played around with your flags
> in various configurations but so far **no success**.  What I really need
> to know is whether these are the flags are passed to the cinelerra build
> process as a whole or whether your script is building cinelerra in parts
> and these flags were just those given to the internal ffmpeg.  Or
> perhaps the make in the quicktime directory?

to the build process as a whole. As far as I can see, the debian buildscript
passes this flags to configure. The CONFFFLAGS are passed directly as command
line flags to configure, and the other are passed in some of the multible
ways you describe to ./configure, which on its part just builds those flags
into every generated makefile. The net effect is, that *every* compiler
invocation sees the
CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops -minline-all-stringops
- -fprefetch-loop-arrays -fPIC
CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops -minline-all-stringops
- -fprefetch-loop-arrays -fPIC -fno-check-new

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)


> When I tried them on cinelerra as a whole I got various different
> results but so far none of them look like progress.

But the problem is allways in the included ffmpeg directory?

>
> 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
>
so something in the generated comandline has been messed up.
Another hint: you can copy out the commandline of the MAKE output
then just walk into the directory and try it out on a single file.
So you find out the correct one.
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).

When the problem ist just one subdirectory, you can try to get it
compiled separately (as Hannes proposed). When the main MAKE-process
is re-started, it just checks that ther are the compiled *.o files
in this directory and happily proceeds with the next directory.
The last important command in the build process is allways the link
command. You can easily spot it in the output, because it contains
a long list of *.o files and finally the executalble or lib to be linked.
This ist the command which fails when some of the Objects were compiled
with wrong or just differing swichtes (e.g. mixed -fpic or -fPIC  ;-)
you see, in the course of time you just get paranoid )

Cheers,
Hermann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGMNZXZbZrB6HelLIRApnrAJ9OX6nIztWW8521qMpsaJaDcJ/JwgCgr5cn
rOxBwFjwBGBHjKVNsUV23Mg=
=x2Oj
-END PGP SIGNATURE-

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

Hi Hermann

work. On debian, this is very common a problem with the libx264. So they 
(DEBIAN,UBUNTU)
provide in their package both versions, one built with -fpic and one built with 
-fPIC. So all
you have to do there is to walk to /usr/lib and put a symlink  ln -s 
libx264_pic.a libx264.a
I myself found out about this after spending hours and hours trying to build 
some dependencies.
AArrrgh. Of course it is stated in the README, but who is able to read all 
READMEs of all
packages he is using??

  
I've actually built a new x264 according to some instructions I found on 
a ubuntu forum.  I'm pretty sure I got that part right -also none of my 
errors seem to relate to x264 so far.

I did my last cinelerra build some months ago, and I used the following in the 
Debian buildfile

ifeq ($(DEB_HOST_ARCH),amd64)
CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops 
-minline-all-stringops
- -fprefetch-loop-arrays -fPIC
CXXFLAGS=$(CFLAGS) -fno-check-new
CONFFLAGS+=--enable-sse3 --with-pic
endif

  
This is excellent detail thank you.  I've played around with your flags 
in various configurations but so far **no success**.  What I really need 
to know is whether these are the flags are passed to the cinelerra build 
process as a whole or whether your script is building cinelerra in parts 
and these flags were just those given to the internal ffmpeg.  Or 
perhaps the make in the quicktime directory?


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

When I tried them on cinelerra as a whole I got various different 
results but so far none of them look like progress.

Of course your situation is different; I would guess the CONFFLAGS are the flag 
passed
to ./configure, which you are invoking by hand, and you can put the CFLAGS and 
CXXFLAGS
into the environement prior to invoking ./configure, so they are picked up and 
written
into every generated makefile (is that the way it works? not sure though).

  
I have found two different ways that seem to work.  On the main 
cinelerra build:

./configure -xxx -xxx CFLAGS="" CXXFLAGS="" FFMPEGCFLAGS=""
and also
./configure -xxx -xxx
make CFLAGS="" CXXFLAGS=""

and just
make CFLAGS="" CXXFLAGS=""
for trying to build from the ffmpeg directory.

I know building is hell, but you can survive it (most of us survived it) ;-)
  
I want my cinelerra back so I will get this worked out.  Or perhaps vale 
will update amd 64 packages for opengl and bluedot.  big hint!  Maybe 
I'll be expert enough by the end of this to do it myself.

Hope that helps

  

it helps even if it doesn't.

thanks again.
Graham E

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Ichthyostega]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Ellison schrieb:
> Are you sure about the syntax? I thought one did
> 
> CXXFLAGS="-fPIC"
> make

Hello,

about the syntax: the point is to get the option through to the
compiler. In your example some mails back, you set

> CFLAGS="-O0 -g"
and correctly get
> gcc -DHAVE_CONFIG_H -I.  [..shortended ...]   -DHAVE_AV_CONFIG_H 
> -I./../.. -I../.. -O0 -g
   NOTE 
^^^
so my conclusion is, that this part works as expected.


Graham,

there are always several possible sollutions, but the aproach proposed by 
Hannes seems
reasonable, if nothing else helps, trying to build the internal ffmpeg with 
different
options.

I can't tell you exactly what your problem is, (because I am on Debian (AMD64)  
and Ubuntu (32bit)).

But the point, is, you need to get the right options through to the compiler. 
My knowledge with
compiler options is rather limited, but at least, I think you should have 
allways

- -march=athlon64 -msse3 -fPIC

i.e. you should check that this opitons are really present on the real compiler 
call happening
in the build process. If you have problems viewing the compiler output (because 
it is so much
and goes by so fast), you can redirect all output into a file and look at this 
file with less
from another terminal while the build is going on. You can do this e.g. by:

YOUR_CMDLINE_TO_START_BUILD   2>&1 |tee proto.txt

To my knowledge, the -march is important, because it tells the compiler you are 
on AMD64,
the sse3 superseeds all other sse1, sse2, mmx and the like (have a look at 
wikipedia...)
and the -fPIC is really what you need to get the shared objects consistent and 
working.
If there is only a single part that was built e.g. with -fpic, then the linking 
won't
work. On debian, this is very common a problem with the libx264. So they 
(DEBIAN,UBUNTU)
provide in their package both versions, one built with -fpic and one built with 
-fPIC. So all
you have to do there is to walk to /usr/lib and put a symlink  ln -s 
libx264_pic.a libx264.a
I myself found out about this after spending hours and hours trying to build 
some dependencies.
AArrrgh. Of course it is stated in the README, but who is able to read all 
READMEs of all
packages he is using??

I did my last cinelerra build some months ago, and I used the following in the 
Debian buildfile

ifeq ($(DEB_HOST_ARCH),amd64)
CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops 
-minline-all-stringops
- -fprefetch-loop-arrays -fPIC
CXXFLAGS=$(CFLAGS) -fno-check-new
CONFFLAGS+=--enable-sse3 --with-pic
endif

Of course your situation is different; I would guess the CONFFLAGS are the flag 
passed
to ./configure, which you are invoking by hand, and you can put the CFLAGS and 
CXXFLAGS
into the environement prior to invoking ./configure, so they are picked up and 
written
into every generated makefile (is that the way it works? not sure though).

I know building is hell, but you can survive it (most of us survived it) ;-)
Hope that helps

Cheers,
Hermann Vosseler


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGMLY/ZbZrB6HelLIRAjKKAJoDbNGR0wpbq6mOrRoknvf4dt+0DACeNLy6
lPTw4RNv6jtl1hNd2gFTYwA=
=dbyN
-END PGP SIGNATURE-

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

Are you sure about the syntax? I thought one did

CXXFLAGS="-fPIC"
make

or

CXXFLAGS="-fPIC" make

not sure -although I sourced my syntax off the web- but #2 didn't work 
either.

Thanks Martin

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Martin Ellison]

Are you sure about the syntax? I thought one did

CXXFLAGS="-fPIC"
make

or

CXXFLAGS="-fPIC" make


On 26/04/07, Graham Evans <[EMAIL PROTECTED]> wrote:



>
> I will try some other CFLAGS but with my lack of skills in this area I
> will need to be very lucky...
>
> Graham E.
I tried things like:

make CXXFLAGS=-fPIC
make OPTCFLAGS=-fPIC
make CFLAGS=-fPIC
make CXXFLAGS="3D-g -fPIC"

You can probably tell the level of my skills from the flags I used -
these I found from googling ffmpeg /amd64 compile problems.

Anwyay the builds were all successful but then when I cd ../.. && make
the total build fails as before.  And now I need to give up again until
I receive further advice.

Graham E

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra





--
Regards,
Martin
([EMAIL PROTECTED])

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

Please tell why you can't do dynamic builds. Themes and plugins are
loaded dynamically as modules, they really need dynamic builds. Changing
this would be not trivial (using libltdl for the module loader for example).

I suggest to fix dynamic builds rather than trying static builds.

Once I had the same error, but it turned out that set GLOBAL_PLUGIN_DIR
wrong (from a former test). Running cinelerra under strace control will
reveal such cases (what files/paths it searches and which ones fail).
  

Running strace cinelerra didn't produce anything meaningful to my eyes.

The attempt to static build was just to get around amd 64 compile 
problems - to do with ffmeg/libavcodec linking (see the svn 1008 build 
failure thread).  It sounds like I have just used impossible configure 
options (--disable-shared, --enable-static, -with/without-fpic etc...)


If you still want me to play around with strace or post or email you 
output let me know...


Graham

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

I will try some other CFLAGS but with my lack of skills in this area I 
will need to be very lucky...


Graham E.

I tried things like:

make CXXFLAGS=-fPIC
make OPTCFLAGS=-fPIC
make CFLAGS=-fPIC
make CXXFLAGS="3D-g -fPIC"

You can probably tell the level of my skills from the flags I used - 
these I found from googling ffmpeg /amd64 compile problems.


Anwyay the builds were all successful but then when I cd ../.. && make 
the total build fails as before.  And now I need to give up again until 
I receive further advice. 


Graham E

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Graham Evans]

sorry Hannes - not sure how that got sent to personal address...
You can try to build the internal ffmpeg with different optimization 
options like this:


$ make
 terminates with an error
$ cd quicktime/ffmpeg
$ make clean
$ make CFLAGS='-O0 -g'
 hopefully works...
$ cd ../.. && make

Try different optimization levels in CFLAGS.

-- Hannes

  
Okay so I configure without any flags at all then when it breaks I move 
to the ffmpeg directory, make clean and the make CFLAGS="-O0 -g".  After 
a second of building this produces an error:
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../.. -O0 -g -MT fdct_mmx.lo -MD -MP -MF 
.deps/fdct_mmx.Tpo -c fdct_mmx.c -o .libs/fdct_mmx.o/tmp/ccdU7310.s: 
Assembler messages:

/tmp/ccdU7310.s:2075: Error: suffix or operands invalid for `pshufw'
make[2]: *** [fdct_mmx.lo] Error 1
make[2]: Leaving directory 
`/home/gray/install/hvirtual/quicktime/ffmpeg/libavcodec/i386'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/gray/install/hvirtual/quicktime/ffmpeg/libavcodec'

make: *** [all-recursive] Error 1

If I run make in the ffmpeg directory with no flags then it builds 
successfully.  Then when I cd ../.. && make I get the same exit as before:


/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

collect2: ld returned 1 exit status
make[3]: *** [libquicktimehv.la] Error 1
make[3]: Leaving directory `/home/gray/install/hvirtual/quicktime'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/gray/install/hvirtual/quicktime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `

I will try some other CFLAGS but with my lack of skills in this area I 
will need to be very lucky...


Graham E.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Johannes Sixt]

On Wednesday 25 April 2007 17:02, Graham Evans wrote:
> It seems all these problems have come up before but I can't find the
> solutions.  Apparently the themes aren't building properly because of
> the static linking options I've used in my configure line.  But I can't
> get a successful build without those options...

Right, you can't build cinelerra statically (--disable-shared --enable-static)

You can try to build the internal ffmpeg with different optimization options 
like this:

$ make
 terminates with an error
$ cd quicktime/ffmpeg
$ make clean
$ make CFLAGS='-O0 -g'
 hopefully works...
$ cd ../.. && make

Try different optimization levels in CFLAGS.

-- Hannes

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Christian Thaeter]

Graham Evans wrote:
> Martin Ellison wrote:
>> Maybe it's your path. It seems that it is looking in the wrong place.
>>
> It seems all these problems have come up before but I can't find the
> solutions.  Apparently the themes aren't building properly because of
> the static linking options I've used in my configure line.  But I can't
> get a successful build without those options...
> 
> Static and dynamic linking is beyond my knowledge at present so my
> remaining options are:
> sacrifice open gl and try out the http://giss.tv/~vale deb packages,
> perhaps try and compile with an old external ffmpeg (mid 2006 cvs is not
> early enough and earlier than that is likely to mess with my other sid
> programs), or
> open up my fedora core 4 64 partition which runs latest cinelerra CV no
> probs...

Please tell why you can't do dynamic builds. Themes and plugins are
loaded dynamically as modules, they really need dynamic builds. Changing
this would be not trivial (using libltdl for the module loader for example).

I suggest to fix dynamic builds rather than trying static builds.

Once I had the same error, but it turned out that set GLOBAL_PLUGIN_DIR
wrong (from a former test). Running cinelerra under strace control will
reveal such cases (what files/paths it searches and which ones fail).

> 
> Thanks for the suggestions anyway...  if anyone thinks of anything else
> I'd be glad to hear from them.
> 
> Graham E.
> 
> 
>> On 25/04/07, *Graham Evans* <[EMAIL PROTECTED]
>> > wrote:
>>
>>
>> I run a fresh cinelerra install (had some problems building - see
>> thread
>> '[CinCVS] build failure svn 1008').  There is currently no ~/.bcast
>> directory and I get a crash after a brief flash of life:
>>
>> MWindow::init_theme: theme S.U.V. not found.
>>
> 
> 
> ___
> 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] theme S.U.V. not found

[Graham Evans]

Martin Ellison wrote:

Maybe it's your path. It seems that it is looking in the wrong place.

It seems all these problems have come up before but I can't find the 
solutions.  Apparently the themes aren't building properly because of 
the static linking options I've used in my configure line.  But I can't 
get a successful build without those options...


Static and dynamic linking is beyond my knowledge at present so my 
remaining options are:

sacrifice open gl and try out the http://giss.tv/~vale deb packages,
perhaps try and compile with an old external ffmpeg (mid 2006 cvs is not 
early enough and earlier than that is likely to mess with my other sid 
programs), or
open up my fedora core 4 64 partition which runs latest cinelerra CV no 
probs...


Thanks for the suggestions anyway...  if anyone thinks of anything else 
I'd be glad to hear from them.


Graham E.


On 25/04/07, *Graham Evans* <[EMAIL PROTECTED] 
> wrote:



I run a fresh cinelerra install (had some problems building - see
thread
'[CinCVS] build failure svn 1008').  There is currently no ~/.bcast
directory and I get a crash after a brief flash of life:

MWindow::init_theme: theme S.U.V. not found.




___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] theme S.U.V. not found

[Martin Ellison]

Maybe it's your path. It seems that it is looking in the wrong place.

On 25/04/07, Graham Evans <[EMAIL PROTECTED]> wrote:



I run a fresh cinelerra install (had some problems building - see thread
'[CinCVS] build failure svn 1008').  There is currently no ~/.bcast
directory and I get a crash after a brief flash of life:

MWindow::init_theme: theme S.U.V. not found.

Running as root makes no difference.  I tried copying a ~/.bcast from an
old installation and this time it fails with:
MWindow::init_theme: theme Blue Dot not found.

I have checked and the bluedot and suv themes were installed into
/usr/local/lib/cinelerra as expected.  Obviously my problems might
relate to the options and steps I had to go through to build.  Any ideas
will be very appreciated.

Graham E.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra





--
Regards,
Martin
([EMAIL PROTECTED])

[CinCVS] theme S.U.V. not found

[Graham Evans]

I run a fresh cinelerra install (had some problems building - see thread 
'[CinCVS] build failure svn 1008').  There is currently no ~/.bcast 
directory and I get a crash after a brief flash of life:


MWindow::init_theme: theme S.U.V. not found.

Running as root makes no difference.  I tried copying a ~/.bcast from an 
old installation and this time it fails with:

MWindow::init_theme: theme Blue Dot not found.

I have checked and the bluedot and suv themes were installed into 
/usr/local/lib/cinelerra as expected.  Obviously my problems might 
relate to the options and steps I had to go through to build.  Any ideas 
will be very appreciated.


Graham E.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra