New answers tagged libraries
RE: your comment on 'never seen it in Windows' Windows avoids this because nearly every program installs an extra copy of the major libs that it uses in its own directory, so you end up with dozens of copies of the same libs installed. This is why you often see setup.exe or similar installers re-installing the same libs like Direct X or Dot Net or Visual ...
I had not upgraded my Arch server in a few weeks: ncurses has indeed changed to version 6 as of early September, but PHP should have been upgraded with it. The quick-n-dirty fix is: pacman -U /var/cache/pacman/pkg/ncurses-5.9-7-i686.pkg.tar.xz You can install PHP via pacman. There'a a number of pieces that I've found necessary, including php, php-apache, ...
Having multiple versions of a library in the system is not an issue in most Linux distributions: shared libraries with distinct sonames can coexist within the same /usr/lib directory. Moreover, package managers can be instructed to install several such libraries by specifying correct package names: apt-get install libjpeg7 apt-get install libjpeg8 In ...
Short answer: No. For some distributions, this is the case. Longer answer: Linux is the kernel, not a distribution. If you use a distribution like NixOS, it's easy to have several versions of the same library installed at the same time.
You can find old packages in the snapshots archive. However, downgrading packages is generally not supported in Debian, so if anything breaks, you've got to keep the pieces. I also recommend using a separate chroot for such experiments.
To check which library the app is using use ldd ldd /path/to/application also read up on ldconfig.
Since OpenCV is a C library with python bindings rather than a python one, you need to tell the C environment to look in the correct library path, as well as the python one. To do that, use LD_LIBRARY_PATH. Assuming the OpenCV .so file is (say) $HOME/opencv-3.0/lib/libopencv.so.3, you do the following: LD_LIBRARY_PATH=$HOME/opencv-3.0/lib ...
The subsystem is listed in this line: E: SUBSYSTEM=power_supply However, it appears as if the battery and AC adapter do not have a devtype and therefore it is perfectly acceptable to pass NULL to the function as an argument in place of a devtype. In this case, the function call looks like this: udev_device_get_parent_with_subsystem_devtype(dev, ...
Did you try setting --libexecdir=DIR during configuration? According to --options, this should set program executables [EPREFIX/libexec]
There doesn't appear to be some general environment variable I can set. In the case of mesos, I needed to pass in --launcher_dir=/opt/deploy/mesos/libexec/mesos/ when launching the slave. Alternatively, the environment variable MESOS_LAUNCHER_DIR can also be used.
Top 50 recent answers are included