Another week when the fed took $20 billion out of the stonk market, but the stonk market charged higher, approaching its all time highs.  Plenty of cash to buy stonks & no commitment of the fed to do what it says it's going to do.  Like the summer, there was another rumor that the fed was about to pivot.  Lions continue to observe lack of inventory & rising prices.

Lions noted a recent influx of foreign plates.  Lots of layoffs in Texas & NY.  Animals are getting told to come to Calif* to have a job.

Priorities turned to figuring out a way to make Cinelerra run on more linux derivatives without recompilation.

The lion kingdom decided to dive into appimage creation.  The mane problem is licensing.  It would be easy enough for a program to copy every dependency for your program & bundle just those dependencies in a root image.  The problem is distributing all those binaries without the licensing would be illegal.  

Instead, they require providing the source for every debian package used in building it.  Besides being super complicated, it requires all the contents of every package to be included instead of just the 1 library.  It copies the license files for every single dependency, a lot of X window utilities, a lot of X config files.  There's also the problem where forgetting to name a dependency causes the program to revert to the host library.  So many animals are creating appimages & forgetting dependencies, they're about as good as tar balls were.

Some dependencies can't be reverse engineered automatically, like a utility in a system call or a library loaded in a dlopen call.  Those would need a .yml file.

What's most intriguing is how it replaces the host ld.so with its own.  It's something lions never could get working with LD_LIBRARY_PATH or chroot.  ld.so always had to be in /lib & there could only be 1.  The appimage's ld.so is in /opt/libc/lib/x86_64-linux-gnu/ & it now does seem to get picked with an LD_LIBRARY_PATH.  

Maybe the need grew enough for someone to finally fix ld.so to run from anywhere.  Maybe that was done so it could run a 32 bit program from /lib32 or a 64 bit program from /lib64

Most of the dependencies for gyroflow get picked up with

LD_LIBRARY_PATH=opt/libc/lib/x86_64-linux-gnu/:opt/libc/usr/lib/x86_64-linux-gnu/:usr/lib/x86_64-linux-gnu/:usr/lib/x86_64-linux-gnu/pulseaudio/ ./gyroflow

but not the missing xcb_randr_get_monitors.  Despite being in an appimage, their .yml file didn't include the X11 libraries so the appimage still doesn't work.

The lion kingdom still needs a recursive symbol finder which searches through every .so file in a directory tree for a symbol.  Unfortunately, the gyroflow dependencies are all stripped.

Maybe an old fashioned script which just sets LD_LIBRARY_PATH & runs the thing is good enough.  There could be a way to automatically bundle all the system libraries from ldd along with a user supplied directory containing the dependencies not listed by ldd.

Cinelerra itself has no CUDA dependencies.  It only uses the binary nvidia GL libraries.  The ffmpeg binary with GPU support has CUDA dependencies which seem to all be static.  Cinelerra is different in that it doesn't depend on a global gnome framework, a global systemd framework, a global udev configuration, a dedicated user account, or a certain global configuration of the system.  It depends on only its own files.

The whole ld.so matter got lions wondering if an ubuntu 16 build environment really needs to be in a virtual machine.