 |
Obviously, the mod does more than just compile "libzmpeg3". Together with "libzmpeg3", "cin" now also compiles. Debian binary package built, compiled with: ./configure --prefix=/usr --with-jobs=8 \ --without-oss --without-opencv --disable-dav1d --with-clang (Whereby the compilers gcc, g++ etc. under /usr point to clang, as described below.) A first short test run with and without plugins shows no abnormalities and also no relevant differences in the achieved frame rate. dav1d: The respective argument for adjusting the stack "-mpreferred-stack-boundary" (gcc) or "-mstack-alignment" (clang) is irrelevant to me. My future quantum computer has certainly built in a hardware decoder for AV1. Until then, I'd love to do without editing AV1 material. |
 |
Based on the log files (thank you for supplying them which helped) GIT checkin now includes a mod to allow for compiling using clang for libzmpeg3. It worked here when testing with Fedora 30 O/S. What I mean by "fix" is the type of stuff necessary for O/S, like Arch, as you passed along to Andrea in note 2132. |
|
|
I have no idea what you mean by "fix." make_cin_clang.log (38,644 bytes) make_libzmpeg3_clang.log (26,898 bytes) |
|
|
I should have mentioned that what was checked in for a clang build is what worked on Fedora 30 on our desktop. libzmpeg3 was deliberately left as compiling in gcc because of inline MMX assembly code. An earlier test for us showed that using clang performed quite a bit slower. Anyway, awhile back, a BSD programmer was getting CinelerraGG to run and they compiled what they could using clang. Various distros probably will have varying results compiling with clang and anyone using this will have to "fix" it for their distro most likely. |
|
|
@Andrea_Paz, the new switch "--with-clang" does essentially what the Arch wiki describes. But this is apparently not enough. For a test run, make sure that the programs cc, c++, cpp, gcc, g++ point to clang, clang++ and clang-cpp. |
 |
I simply installed clang and then I compiled CinGG. I see now on the Arch wiki that I had to configure makepkg.conf adding "export CC=clang" and "export CXX=clang++". Which I didn't do, so the test with "--with-clang" is useless and I apologize. |
|
|
@Andrea_Paz: "maybe it's better to delete everything and re-download from scratch?" make clean ; ./autogen.sh ; ./configure ... From your log: cin5-clang.log:3717:checking whether C compiler accepts -mpreferred-stack-boundary=4... yes All variables set correctly? Because: "clang: error: unknown argument: '-mpreferred-stack-boundary=5'" (Error 2) @PhyllisSmith, this is interesting, I only thought of other (better) error messages. For information only, at libzmpeg3 every time is over, abort with error 2. (/usr/bin/gcc -> clang* /usr/bin/g++ -> clang++* $ echo $CC $CXX /usr/bin/clang /usr/bin/clang++ ./configure --prefix=/usr --with-jobs=8 --without-oss --without-opencv --without-vaapi --disable-dav1d --with-clang) |
|
|
I attach cin5.log for gcc and clang. cin5log.tar.gz (595,814 bytes) |
|
|
I did some tests compiling with gcc and clang. Between one test and the next I did a "make clean" (maybe it's better to delete everything and re-download from scratch?). I then playback WhatTimeIsIt.xml by Igor. These are the results: Compile time: clang 21' gcc 19' (as always) Size cinelerra5 folder: clang 2.7GB gcc 2.9GB Playback: clang 8/9 fps gcc 8/9 fps |
|
|
I have added this to my local documentation for later addition to the LaTex version manual. It will be in the Installation section as: "To do a single-user build, read the README that is at the top level after you get the source. ... NOTE: if your system has never had Cinelerra-GG Infinity installed, you will have to make sure all of the compilers and libraries necessary are installed – for example Cinelerra-GG is dependent on "GNU C compiler" (gcc). Meanwhile, there is now an option on the configure for the build to use "clang" for most of the compilations (not all, but maybe about 90%). You would have to use --with-clang to use this option. The reason for adding the clang possibility is because in a single small test case here, there was about a 10% speedup on the media decode. |
- Anonymous
