[CinCV TNG] Can't disable ladspa

Phyllis Smith phylsmith2017 at gmail.com
Sun Jun 3 01:06:47 CEST 2018


On Sat, Jun 2, 2018 at 3:42 PM, Yuri <yuri at rawbw.com> wrote:

> On 06/02/18 12:11, Phyllis Smith wrote:
>
>
>> Because we build cin5 across so many different distros, the makefile has
> to be flexible to work for most of them and thus sometimes a "force" is
> necessary.  In the case of libogg - ilmbase, theora, vorbis, openexr and
> maybe even ffmpeg - expect libogg to be there.  Cinelerra-gg may not work
> as well as it should if a user builds without some libraries.  Sad
> experience has shown
> that it is better to build in a known version (which also makes it
> possible to debug), rather than use "some" version on a system.
>
>
> On FreeBSD bundling is discouraged. Also bundling assumes that the package
> is easy to build, but most projects only build easily on Linux, and require
> patching on BSD. CinelerraGG is a great example: it doesn't build out of
> the box. I would still prefer to use the pre-installed libogg.
>
> In CinelerraGG you use gcc in makefiles, assuming that it is installed.
> Instead, we use clang, and the right way is $(CXX). You also use 'make' in
> makefiles, assuming that make is always called 'make', when the right way
> is to use $(MAKE). I am patching all these places.
>
>
> Also, because a lot of computer people expect "autoconfigure", it is part
> of the build process, but GG does not like it.
> The last round of modifications have left it in a sorry condition.  LV2 is
> in there twice, and we intend to drop the LV2UI option.
> There is still a bunch of pending clean up needed.   If you have fixes,
> please let us know.
>
> Hope this helps get you further along, and please let us know if we can
> help as we have always become stuck on FreeBSD.
>
>
> So far I didn't succeed, it will require some more efforts.
>
>
> Now it fails with:
> affine.C:703:13: error: allocating an c++ `cat amd64/c_flags`
> -DMSGQUAL=performanceprefs -c performanceprefs.C -o amd64/performanceprefs.o
> object of abstract class type 'AffineUnit'
>         return new AffineUnit(this);
>                    ^
> /usr/ports/multimedia/CinelerraGG/work/CinelerraGG10-11a9793/
> cinelerra-5.1/libzmpeg3/thread.h:54:16: note: unimplemented pure virtual
> method 'Proc' in 'AffineUnit'
>   virtual void Proc () = 0;
>                ^
>
>
>
> Looks like the include file search path is wrong.   This version of the
Thread class is only
used in libzmpeg3, not in the cinelerra main app.   That version is in
guicast.  The builds
here use these file paths in the directory makes.  I am *guessing* that you
used a global
include search path which always includes libzmpeg3 first, but I cannot say
for sure why
the file the compiler uses is the wrong choice.

If you look in the same directory as affine.C, in x86_64/c_flags you can
see the CFLAGS
that was used in the compiler call created by the makefile recipe.  It will
include guicast
first if you want to access the correct thread.h

Summary:
configure.ac creates configure
configure creates global_config
cinellera/Makefile reads global_config and creates/uses x86_64/c_flags

To change this means probably to add CFLAGS to one of those steps.

gg


Yuri
>
>
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20180602/85fb88da/attachment.html>


More information about the Cinelerra mailing list