Hey there,
I have just dropped the cinelerra-cv package from the official
repositories on Arch Linux (to the AUR). Initially I planned on
replacing it with cinelerra-gg, but I don't think this is very feasible
at this point in time.
I started to attempt a build, that is dynamically linked against the
required system libraries [1], but it seems to be an equal amount of
work compared to cinelerra-cv, which is not at all feasible. This is not
because of the libraries themselves failing to work or missing symbols
or anything like that, but because the build system actively prevents
building a dynamically linked application!
However, I already hack-fixed a great deal of things compared to the
upstream provided attempt [2] (on a static build), which really doesn't
need to depend on all the packages, that the PKGBUILD lists in
depends=() (because of its static nature).
That aside, a static build of this size in the official repositories of
Arch Linux is not ever going to become a reality (nor in any other
distribution), if nearly all of the components are available as a
package. Therefore I would like you to consider to fix a great deal
regarding the build system of cinelerra-gg to remedy this situation and
move towards a (mostly) dynamically linked application instead.
I believe this can be fairly straight forward with dynamic rebuilds
against different versions of the required libraries in a continuous
integration pipeline! The tools are there.
In case static builds is what you will be going for no matter what,
disregard the rest of my e-mail.
That being said, I had to hack in nearly all of the --libs (which could
just easily be gotten by calls to pkg-config, instead of hardcoding some
of them or just not making them available at all) and also some of the
--cflags for lv2 integration.
I'm left with a (working!) application (probably with a bunch of broken
edges), that - unfortunately - doesn't feature full RELRO [3] (because
LDFLAGS are not propagated throughout all the components), PIE [4] (not
implemented), has executable stack [5] (which I haven't encountered
before with any of the other software I package, but is apparently
pretty bad) and *a lot* of "unused shared library" references (due to
the bizarre "libs" files being used to store all the library names
instead of dynamically assembling them, when needed).
The naming of the project, its subdirectories and
(un-)declared/undocumented thirdparties (which of them are real
thirdparties, which are your own/modified?) are confusing.
The project does not (yet) have a form of versioning (at least not
reflected in actual git tags), unless you're up for using calver (I
recommend semver to actually be able to discern different levels of
stability, feature availability and to work towards a roadmap).
Considering providing (unsupported) builds for Arch Linux: Please use
the AUR for providing PKGBUILDs and name the package according to your
upstream (cinelerra-gg), unless you have the intent to rename the
project. Make sure to use devtools [8] (e.g. `extra-x86_64-build -c` in
the directory of the PKGBUILD) to build your package. It will give you
*a lot* of additional information, as the package build is done in a
pristine containered build, using systemd-nspawn.
In case cin [7] is done by you: Please, never push binary data to the
repositories!
Closing, please don't get me wrong: It's your project and all, but this
is a situation, that will drive away any potential packager of the
software as it's just too complicated to plainly build (no matter the
eventual runtime problems one might get)!
I know this project has come a long way, but I believe it would benefit
from a general cleanup and restructuring, which will render it much more
accessible!
Best,
David
P.S.: If you have any questions regarding the Arch Build System (ABS),
or packaging on Arch Linux, or my PKGBUILD (which was still a WIP, when
I stopped), shoot away!
[1] http://pkgbuild.com/~dvzrv/aur/cinelerra-gg/PKGBUILD
[2] https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/blds/PKGBUILD;h=04473dad26ce167c3a7aeb7905679e15cd175241;hb=HEAD
[3] https://mudongliang.github.io/2016/07/11/relro-a-not-so-well-known-memory-corruption-mitigation-technique.html
[4] https://en.wikipedia.org/wiki/Position-independent_code
[5] https://en.wikipedia.org/wiki/Executable_space_protection
[6] https://aur.archlinux.org
[7] https://aur.archlinux.org/cgit/aur.git/tree/?h=cin
[8] https://www.archlinux.org/packages/extra/any/devtools/
--
https://sleepmap.de
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin