Home
Help
Search
Login
Register
Recent Posts1
Programming / Re: Linux Dependency Black Hole
« Last post by macboy on Today at 03:48:59 pm »I am not a Linux dependency expert, but I have learned a few things over the years. First: use a good distro. The various libraries included in a distro release are tested to work together. So if something needs XYZlib, then when you install XYZlib using the distro's tools (apt, etc.), it will not break the system. Unfortunately, this version of XYZlib is probably more than a year old - maybe a few years - and might not satisfy the requirements of the tool you are trying to install or build.
You can try a chroot or one of the many variations of this. This allows you to install an complete alternate root filesystem, which still runs on the present kernel, but is isolated from the system's main root filesystem. You could install the same system (but different packages/libraries), or a different release of the O/S (Debian 10, on a system running Debian 12), or a different distro (Arch Linux on Debian system), or even a different architecture (Debian for armhf on a Debian x64 system), in combination with qemu. The point of doing this, is that you can install a minimal O/S, then install only the dependencies for the application in question, then try to resolve the dependency issues. Since the number of installed packages is much smaller, the dependencies to resolve will be fewer, hopefully. This also avoids breaking the main system by installing some different version of something outside of the distro package system.
Alternately, you can try building the application with static linkage, so that it does not depend on installed shared libraries at all. Instead, all of the shared library code will be built into the executables. The dependencies are installed only for compilation (e.g. XYZlib-dev). You may/will choose to do this inside a chroot as well, to isolate the installation of the many build tools, dev libraries, etc. from the main Linux system. After the app is built, installed, and tested, you could delete (or archive) the chroot to save space. The static-linked binaries will be bigger, sometimes much bigger, but as a bonus they usually run faster as well.
You can try a chroot or one of the many variations of this. This allows you to install an complete alternate root filesystem, which still runs on the present kernel, but is isolated from the system's main root filesystem. You could install the same system (but different packages/libraries), or a different release of the O/S (Debian 10, on a system running Debian 12), or a different distro (Arch Linux on Debian system), or even a different architecture (Debian for armhf on a Debian x64 system), in combination with qemu. The point of doing this, is that you can install a minimal O/S, then install only the dependencies for the application in question, then try to resolve the dependency issues. Since the number of installed packages is much smaller, the dependencies to resolve will be fewer, hopefully. This also avoids breaking the main system by installing some different version of something outside of the distro package system.
Alternately, you can try building the application with static linkage, so that it does not depend on installed shared libraries at all. Instead, all of the shared library code will be built into the executables. The dependencies are installed only for compilation (e.g. XYZlib-dev). You may/will choose to do this inside a chroot as well, to isolate the installation of the many build tools, dev libraries, etc. from the main Linux system. After the app is built, installed, and tested, you could delete (or archive) the chroot to save space. The static-linked binaries will be bigger, sometimes much bigger, but as a bonus they usually run faster as well.
). According to her there is one cat in the park who allows it to be petted / played with (and she showed me a video).