I check for the existence of installed tools via shutil.which()
Both tools are installed via apt get install ffmpeg mediainfo and their binaries are located in /usr/bin with the same file flags and ownership in the host system:
lala#lala:/usr/bin$ ls -la ff*
-rwxr-xr-x 1 root root 301544 May 19 2022 ffmpeg
-rwxr-xr-x 1 root root 22920 Feb 14 2022 ffmpegthumbnailer
-rwxr-xr-x 1 root root 149984 May 19 2022 ffplay
-rwxr-xr-x 1 root root 178832 May 19 2022 ffprobe
lala#lala:/usr/bin$ ls -la media*
-rwxr-xr-x 1 root root 47352 Apr 3 2022 mediainfo
-rwxr-xr-x 1 root root 374000 Apr 3 2022 mediainfo-gui
BUT within the virtual environment only one of them is available. The other one simply doe not exist
sh-5.1$ /usr/bin/ffmpeg
ffmpeg version 5.0.2 Copyright (c) 2000-2022 the FFmpeg developers
[... more ...]
sh-5.1$ /usr/bin/mediainfo
sh: /usr/bin/mediainfo: No such file or directory
So what could be the reason, why one binary is available and the other one is not.
Edit: this happens only in the termial / execution environment within pycharm
It turns out that Pycharm installed by flatpak has its own "environment" where one of the binaries was installed - the other one was not.
Related
There are always jpeg decoder libraries pre-installed on Linux like:
/usr/lib/x86_64-linux-gnu/libjpeg.so
/usr/lib/x86_64-linux-gnu/libjpeg.so.62
/usr/lib/x86_64-linux-gnu/libjpeg.so.62.0.0
/usr/lib/x86_64-linux-gnu/libjpeg.so.8
/usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2
What is the difference between the so library? Does libjpeg.so.62 build from libjpeg-turbo?
Firstly, if you run:
ls -l /usr/lib/x86_64-linux-gnu/*jpeg*
you will see that most of the files are just symlinks to the one with the full version, so programs can link against the latest one by specifying an unversioned library in the knowledge that it will point to the latest version:
lrwxrwxrwx 1 root root 17 Oct 20 2016 libjpeg.so -> libjpeg.so.62.2.0
lrwxrwxrwx 1 root root 17 Oct 20 2016 libjpeg.so.62 -> libjpeg.so.62.2.0
-rw-r--r-- 1 root root 436224 Oct 20 2016 libjpeg.so.62.2.0
Secondly, unfortunately I don't have the same files as you else I would help further, but in general, you can find which package a given file comes from like this:
dpkg -S someFile
So, on my system, I can see that libjpeg.a for example, comes from package libjpeg62-turbo-dev
dpkg -S libjpeg.a
libjpeg62-turbo-dev:amd64: /usr/lib/x86_64-linux-gnu/libjpeg.a
Recently I ran into a problem with the Python function ctypes.util.find_library. The function is used to locate shared libraries by name; for example, CuPy uses it to locate cuDNN. In my case, I had several versions of cuDNN installed, and it picked up the latest (as per the documentation). However, the contents of the directory look like this:
$ l /usr/local/cuda-8.0/lib64 | grep -i cudnn
lrwxrwxrwx 1 root root 13 Oct 3 08:21 libcudnn.so -> libcudnn.so.6*
lrwxrwxrwx 1 1000 users 17 Jul 27 2016 libcudnn.so.5 -> libcudnn.so.5.1.5*
-rwxrwxr-x 1 1000 users 79337624 Jul 27 2016 libcudnn.so.5.1.5*
lrwxrwxrwx 1 root root 18 Oct 3 08:21 libcudnn.so.6 -> libcudnn.so.6.0.21*
-rwxr-xr-x 1 1000 users 154322864 Apr 12 2017 libcudnn.so.6.0.21*
lrwxrwxrwx 1 root root 17 Oct 2 10:32 libcudnn.so.7 -> libcudnn.so.7.0.3*
-rwxrwxr-x 1 1000 1000 217188104 Sep 16 05:09 libcudnn.so.7.0.3*
-rw-r--r-- 1 1000 users 143843808 Apr 12 2017 libcudnn_static.a
Even though the latest version is 7.0.3, judging from the symbolic link hierarchy, I would have expected version 6.0.21 to be picked up. My questions are:
Which version would the gcc (or clang) toolchain have picked up during compile-time?
Which version would a C/C++ executable have picked up during run-time?
Is there any kind of information source (an article, a man page, a book, ...) out there that contains explicitly the answers to the first two questions? I tried googling it, but nothing definitive came up.
Traditionally you'd build with a command like gcc -lcudnn. This would find libcudnn.so which points to libcudnn.so.6 which points to libcudnn.so.6.0.21. So libcudnn.so.6.0.21 would be linked at build time.
Traditionally a shared library will contain a "SONAME" which indicates the ABI compatible version to be loaded at runtime. I'm pretty sure that would be libcudnn.so.6 in this case. So building against libcudnn.so.6.0.21 would give you a runtime dependency on libcudnn.so.6 (you can verify this using ldd myprog | grep libcudnn.so).
Probably, but that's not an on-topic question for Stack Overflow ("recommending an off-site resource").
I have this Ubuntu version:
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
I just download oracle-instantclient12.2-basiclite-12.2.0.1.0-1.x86_64.rpm and install the tools using
alien -i oracle-instantclient12.2-basiclite-12.2.0.1.0-1.x86_64.rpm
But I can't find the exp anywhere, just these 2 files
root#localhost:/usr/lib/oracle/12.2/client64/bin# ls -la
total 108
drwxr-xr-x 2 root root 4096 Nov 8 14:47 .
drwxr-xr-x 4 root root 4096 Nov 8 14:47 ..
-rwxr-xr-x 1 root root 43797 Mar 16 2017 adrci
-rwxr-xr-x 1 root root 56984 Mar 16 2017 genezi
The utilities are not part of the basic (or basiclite) package. The instant client download page lists the packages and what they contain. You need to get the tools package, oracle-instantclient12.2-tools-12.2.0.1.0-1.x86_64.rpm, in addition to the basic package, to be able to use exp and imp (and their datapump equivalents; and SQL*Loader).
You may find the SQL*Plus package useful as well.
I currently have awstats 7.0 which is from 2010. I would like to update to current stable relase, which is awstats 7.3
I tried
tar zxf awstats-7.3.tar.gz
cd awstats-7.3
ls -al
drwxr-xr-x 5 puter puter 4096 Jan 29 2014 .
drwxr-xr-x 4 puter puter 4096 Jan 24 23:53 ..
drwxr-xr-x 4 puter puter 4096 Jan 29 2014 docs
-rw-r--r-- 1 puter puter 7020 Jan 29 2014 README.TXT
drwxr-xr-x 5 puter puter 4096 Nov 4 2013 tools
drwxr-xr-x 7 puter puter 4096 Nov 4 2013 wwwroot
./configure
bash: ./configure: No such file or directory
make
make: No targets specified and no makefile found. Stop.
make install
make: *** No rule to make target `install'. Stop.
???
please, advise. Thank you.
I also followed this link
http://www.awstats.org/docs/awstats_upgrade.html
however, I dont really know where to distribute the files on the system.
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.5 (wheezy)
Release: 7.5
Codename: wheezy
If the first command you try to run (./configure) fails (No such file or directory), then probably you should stop right there. The rest of the commands won't work any better.
Did you read the README.TXT file?
Awstats doesn't seem to be a program that needs to be compiled, and it doesn't have a configure script (obviously since you showed the list of files and there isn't one there). I googled for "awstats install" and found this page where it says:
After downloading and extracting the AWStats package, you should run the awstats_configure.pl script to do several setup actions. You will find it in the AWStats tools directory
and you clearly have a tools directory, so I would start with that.
My project uses cmake which tried to look for QT4 which is installed:
root#netqa1:~# which qmake
/usr/bin/qmake
root#netqa1:~# ls -l /usr/lib/i386-linux-gnu/libQtCore.so*
lrwxrwxrwx 1 root root 18 Feb 6 2013 /usr/lib/i386-linux-gnu/libQtCore.so -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Feb 6 2013 /usr/lib/i386-linux-gnu/libQtCore.so.4 -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Feb 6 2013 /usr/lib/i386-linux-gnu/libQtCore.so.4.8 -> libQtCore.so.4.8.1
-rw-r--r-- 1 root root 2998336 Feb 6 2013 /usr/lib/i386-linux-gnu/libQtCore.so.4.8.1
Still I continue to get this error from cmake:
Warning: QT_QMAKE_EXECUTABLE reported QT_INSTALL_LIBS as /usr/lib/i386-linux-gnu
Warning: But QtCore couldn't be found. Qt must NOT be installed correctly, or it wasn't found for cross compiling.
Any pointers will be really helpful
You have probably not installed QT4 dev packets. On Ubuntu this is something like libqt4-dev.
The suffix "dev" stands for development packet.
Adding this option to cmake works for me in Kubuntu 18.04 :
-DQT_QMAKE_EXECUTABLE=qmake-qt4
Original discussion here.