вт, 17 мар. 2026 г., 01:48 Terje J. Hanssen <terjejhanssen@gmail.com>:


On 16/03/2026 20:48, Andrew Randrianasulu wrote:


пн, 16 мар. 2026 г., 22:42 Terje J. Hanssen <terjejhanssen@gmail.com>:


 
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods. 


I do not think our script depend on *version* of packages, just on their *names*.

But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.


The unbundled Cingg I build a month ago had the following config line

CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx

/home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED
(like also readelf) list 69 needed shared libs, attached here


After some editing work of the objdump needed lib list from my Cingg unbundled build, I have generated a package list included summary info on Slowroll using the package manager as follows and excluded the 32bit versions with grep:

zypper se --provides <libs_dep_list> | grep -v 32bit

Attach the list here. As seen I have most all of them (not all variants) that worked for my unbundled build. Extract the package names to make a package install list for build_prepare.sh


After some stackoverflow'ing and reading help I come with this line


cat Slowroll_package_list_for_cinelerra_unbundled_build | grep lib | tail -n 74 | cut -c 6-25 |   tr -d [:blank:]  | sed s/$/-devel/

it gives you this list

ffmpeg-8-mini-libs-devel
glibc-devel
liba52-0-devel
libasound2-devel
libavc1394-0-devel
libavcodec62-devel
libavfilter11-devel
libavformat62-devel
libavutil60-devel
libbz2-1-devel
libdv4-devel
libfftw3-3-devel
libFLAC14-devel
libfontconfig1-devel
libfreetype6-devel
libgcc_s1-devel
libgcc_s1-gcc7-devel
libgcc_s1-gcc13-devel
libgcc_s1-gcc14-devel
libgif7-devel
libGLU1-devel
libglvnd-devel
libiec61883-0-devel
libIex-3_4-33-devel
libIlmThread-3_4-33-devel
libImath-3_2-30-devel
libjbig2-devel
libjpeg8-devel
liblilv-0-0-devel
liblzma5-devel
libmjpegutils-2_2-0-devel
libmp3lame0-devel
libnuma1-devel
libogg0-devel
libOpenEXR-3_4-33-devel
libOpenEXRCore-3_4-3-devel
libOpenEXRUtil-3_4-3-devel
libopus0-devel
libpng16-16-devel
libpulse0-devel
libraw1394-11-devel
libserd-0-0-devel
libsndfile1-devel
libsord-0-0-devel
libsratom-0-0-devel
libstdc++6-devel
libstdc++6-gcc7-devel
libstdc++6-gcc13-devel
libstdc++6-gcc14-devel
libsuil-0-0-devel
libswresample6-devel
libswscale9-devel
libtheora1-devel
libtheoradec2-devel
libtheoraenc2-devel
libtiff6-devel
libtwolame0-devel
libusb-1_0-0-devel
libuuid1-devel
libva-drm2-devel
libva-x11-2-devel
libva2-devel
libvdpau1-devel
libvorbis0-devel
libvorbisenc2-devel
libvorbisfile3-devel
libX11-6-devel
libXext6-devel
libXfixes3-devel
libXft2-devel
libXinerama1-devel
libXv1-devel
libz-ng-compat1-devel
libz1-devel


If zypper reacts positively to some of those lines I guess we can stuff it into script ....





I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)


may be because ldd lists also dependencies of those shared libs ?