I would like to compile libvips with libjpeg-turbo8 to get a better performance, but I'm having trouble replacing it.
When both libjpeg and libjpeg-turbo8 are installed, the regular libjpeg seems to be used during compilation as the performance is quite bad. (I have another docker image where everything does compile properly where it is much faster.)
When I try to remove libjpeg, it will also remove libtiff.
So my question is: How can I compile libvips with libjpeg-turbo8, while keeping libraries that depend on libjpeg?
# apt remove libjpeg8
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
libjpeg-dev libjpeg8 libjpeg8-dev libtiff-dev libtiff5 libtiff5-dev libtiffxx5
0 upgraded, 0 newly installed, 7 to remove and 113 not upgraded.
After this operation, 1664 kB disk space will be freed.
Do you want to continue? [Y/n]
Below a snippet of apt list that shows all installed jpeg libraries:
libjpeg-dev/bionic,now 8c-2ubuntu8 amd64 [installed,automatic]
libjpeg-progs/bionic 1:9b-2 amd64
libjpeg-turbo-progs/bionic-updates,bionic-security 1.5.2-0ubuntu5.18.04.3 amd64
libjpeg-turbo-test/bionic-updates,bionic-security 1.5.2-0ubuntu5.18.04.3 amd64
libjpeg-turbo8/bionic-updates,bionic-security,now 1.5.2-0ubuntu5.18.04.3 amd64 [installed]
libjpeg-turbo8-dbg/bionic-updates,bionic-security 1.5.2-0ubuntu5.18.04.3 amd64
libjpeg-turbo8-dev/bionic-updates,bionic-security,now 1.5.2-0ubuntu5.18.04.3 amd64 [installed,automatic]
libjpeg62/bionic 1:6b2-3 amd64
libjpeg62-dev/bionic 1:6b2-3 amd64
libjpeg8/bionic,now 8c-2ubuntu8 amd64 [installed,automatic]
libjpeg8-dbg/bionic 8c-2ubuntu8 amd64
libjpeg8-dev/bionic,now 8c-2ubuntu8 amd64 [installed,automatic]
libjpeg9/bionic 1:9b-2 amd64
libjpeg9-dbg/bionic 1:9b-2 amd64
libjpeg9-dev/bionic 1:9b-2 amd64
There's no need to rebuild anything -- the two libjpegs are binary compatible and you can simply remove one library binary and install the other.
apt knows how to do this. Just apt install libjpeg-turbo8 and it'll remove the slow libjpeg8, install the new turbo version, and off you go.
Related
I have the most trivial program
$ cat helloworld.c
#include <stdio.h>
int main(void){
printf("Hello World!\n");
return 0;
}
$ gcc -g helloworld.c -o helloworld
Which I'm wanting to run under gdb
$ gdb -tui ./helloworld
When I run, from within gdb,
warning: the debug information found in "/lib64/ld-2.31.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
I think my system is up to date. I've already run
$ sudo apt-get update
$ sudo apt-get upgrade
I've attempted to reinstall any libc6* packages
$ apt list --installed | grep 'libc6'
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6-dbg/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
followed by, for each of those 7 packages, the equivalent of
$ sudo apt-get --reinstall install 'libc6-amd64'
but the warning is the same as previously.
Regarding ld-2.31.so, mentioned by #employedrussian in the comments
$ ls -lsh /lib64/ld-linux-x86-64.so.2
0 lrwxrwxrwx 1 root root 32 Dec 16 2020 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
$ ls -lsh /lib/x86_64-linux-gnu/ld-2.31.so
188K -rwxr-xr-x 1 root root 187K Dec 16 2020 /lib/x86_64-linux-gnu/ld-2.31.so
$ ls -lsh /lib64/ld-2.31.so
180K -rwxr-xr-x 1 root root 178K Dec 16 2020 /lib64/ld-2.31.so
$ dpkg -S /lib64/ld-linux-x86-64.so.2
libc6:amd64: /lib64/ld-linux-x86-64.so.2
$ dpkg -S /lib64/ld-2.31.so
libc6-amd64:i386: /lib64/ld-2.31.so
I've uninstalled libc6-dev-amd64 as identified by #employedrussian below
$ sudo apt-get purge libc6-dev-amd64
$ apt list --installed | grep libc6
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
libc6-dbg/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6-dev/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
libc6/focal-updates,now 2.31-0ubuntu9.2 amd64 [installed,automatic]
libc6/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
But the exact same error reported in gdb remains
/lib64/ld-2.31.so is still present
$ cd /lib64
$ ls -l ld-2.31.so
-rwxr-xr-x 1 root root 182168 Dec 16 2020 ld-2.31.so
libc6-amd64:i386 is still installed
$ dpkg -l | grep libc6-amd64
ii libc6-amd64:i386 2.31-0ubuntu9.2 i386 GNU C Library: 64bit Shared libraries for AMD64
$ apt list --installed | grep libc6-amd64
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libc6-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,auto-removable]
Attempting to remove the package fails
$ sudo dpkg --remove libc6-amd64:i386
[sudo] password for rgh:
dpkg: dependency problems prevent removal of libc6-amd64:i386:
lib64tinfo6:i386 depends on libc6-amd64 (>= 2.16).
lib64ncursesw6:i386 depends on libc6-amd64 (>= 2.14).
lib64ncurses6:i386 depends on libc6-amd64 (>= 2.14).
dpkg: error processing package libc6-amd64:i386 (--remove):
dependency problems - not removing
Errors were encountered while processing:
libc6-amd64:i386
I do remember installing some ncurses packages a while back.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
This appears to be the root cause:
$ dpkg -S /lib64/ld-2.31.so
libc6-amd64:i386: /lib64/ld-2.31.so
According to this answer, libc6-amd64:i386 is a 64bit cross-compile tool-chain prepared for Ubuntu 32bit. Since you are on a 64-bit system, this package is useless.
Uninstalling it will likely fix your warning.
Update:
Trying to understand this
The format in which apt list and dpkg -l show package names is different. On my system:
dpkg-query -l libc6* | grep '^ii'
ii libc6:amd64 2.32-4 amd64 GNU C Library: Shared libraries
ii libc6:i386 2.32-4 i386 GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.32-4 amd64 GNU C Library: detached debugging symbols
ii libc6-dev:amd64 2.32-4 amd64 GNU C Library: Development Libraries and Header Files
ii libc6-dev-i386 2.32-4 amd64 GNU C Library: 32-bit development libraries for AMD64
ii libc6-dev-x32 2.32-4 amd64 GNU C Library: X32 ABI Development Libraries for AMD64
ii libc6-i386 2.32-4 amd64 GNU C Library: 32-bit shared libraries for AMD64
ii libc6-x32 2.32-4 amd64 GNU C Library: X32 ABI Shared libraries for AMD64
versus:
apt list --installed libc6*
libc6-dbg/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev-i386/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev-x32/...,now 2.32-4 amd64 [installed,automatic]
libc6-dev/...,now 2.32-4 amd64 [installed,automatic]
libc6-i386/...,now 2.32-4 amd64 [installed,automatic]
libc6-x32/...,now 2.32-4 amd64 [installed,automatic]
libc6/...,now 2.32-4 amd64 [installed]
libc6/...,now 2.32-4 i386 [installed,automatic]
I believe the package you want to remove is this one:
libc6-dev-amd64/focal-updates,now 2.31-0ubuntu9.2 i386 [installed,automatic]
I want to check the use of the pthread_mutex_lock function, so I execute the command man pthread_mutex_lock, the result appears No manual entry for pthread_mutex_lock.
I checked the information on the Internet and said that there was a No manual entry for pthread_mutex_lock prompt, need to install manpages-posix-dev.
So I'm ready to install manpages-posix-dev（I execute the command: apt-get install manpages-posix-dev）, but E: Unable to locate package manpages-posix-dev prompts me again. Why?I'm using the debian 10 system.
gyz#debian:~$ man pthread_mutex_lock
No manual entry for pthread_mutex_lock
gyz#debian:~$ sudo apt-get install manpages-posix-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package manpages-posix-dev
gyz#debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
gyz#debian:~$ getconf LONG_BIT
64
gyz#debian:~$ cat /proc/version
Linux version 4.19.0-9-amd64 (debian-kernel#lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1
SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
(Even though the question is tagged Debian it appears in generic search results)
The answer for Fedora is that Fedora has removed posix manpages entirely; you need to download/install 'manually' (there's a make installer included in the archive) from https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/
(Thanks to redditors)
On Ubuntu 18.04.1, I have been using lldb and llnode to debug node. I was curious to see if gdb would be any better, so I installed it. After that, lldb failed to load core files anymore.
This worked:
~$ lldb /usr/bin/node -c core
(lldb) target create "/usr/bin/node" --core "/home/ubuntu/core"
Core file '/home/ubuntu/core' (x86_64) was loaded.'
Then I installed gdb:
~$ sudo apt install gdb
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
gdbserver libbabeltrace1 libc6-dbg libdw1
Suggested packages:
gdb-doc
The following NEW packages will be installed:
gdb gdbserver libbabeltrace1 libc6-dbg libdw1
0 upgraded, 5 newly installed, 0 to remove and 19 not upgraded.
Need to get 8737 kB of archives.
After this operation, 51.5 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://us-west-2.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 libdw1 amd64 0.170-0.4 [203 kB]
Get:2 http://us-west-2.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 libbabeltrace1 amd64 1.5.5-1 [154 kB]
Get:3 http://us-west-2.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 gdb amd64 8.1-0ubuntu3 [2937 kB]
Get:4 http://us-west-2.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 gdbserver amd64 8.1-0ubuntu3 [282 kB]
Get:5 http://us-west-2.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 libc6-dbg amd64 2.27-3ubuntu1 [5161 kB]
Fetched 8737 kB in 1s (10.8 MB/s)
Selecting previously unselected package libdw1:amd64.
(Reading database ... 125740 files and directories currently installed.)
Preparing to unpack .../libdw1_0.170-0.4_amd64.deb ...
Unpacking libdw1:amd64 (0.170-0.4) ...
Selecting previously unselected package libbabeltrace1:amd64.
Preparing to unpack .../libbabeltrace1_1.5.5-1_amd64.deb ...
Unpacking libbabeltrace1:amd64 (1.5.5-1) ...
Selecting previously unselected package gdb.
Preparing to unpack .../gdb_8.1-0ubuntu3_amd64.deb ...
Unpacking gdb (8.1-0ubuntu3) ...
Selecting previously unselected package gdbserver.
Preparing to unpack .../gdbserver_8.1-0ubuntu3_amd64.deb ...
Unpacking gdbserver (8.1-0ubuntu3) ...
Selecting previously unselected package libc6-dbg:amd64.
Preparing to unpack .../libc6-dbg_2.27-3ubuntu1_amd64.deb ...
Unpacking libc6-dbg:amd64 (2.27-3ubuntu1) ...
Setting up libc6-dbg:amd64 (2.27-3ubuntu1) ...
Setting up libdw1:amd64 (0.170-0.4) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for man-db (2.8.3-2) ...
Setting up gdbserver (8.1-0ubuntu3) ...
Setting up libbabeltrace1:amd64 (1.5.5-1) ...
Setting up gdb (8.1-0ubuntu3) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Now lldb cannot load the core file anymore:
~$ lldb /usr/bin/node -c core
(lldb) target create "/usr/bin/node" --core "core"
error: core failed to load objfile for /home/ubuntu/core
error: Unable to find process plug-in for core file '/home/ubuntu/core'
How do I fix this? I like lldb better for what I am doing right now and want it back. I tried purging gdb and its additional packages, and then purging and re-installing lldb, but that did not fix anything.
Turns out lldb is terrible at diagnosing and reporting problems with itself. The Unable to find process plug-in error was a direct consequence of the failed to load objfile error.
The failed to load objfile can be caused by anything. In some versions it can be caused by permissions making the core file unreadable. In my case of post hoc, ergo propter hoc, the gdb installation was a red herring. The actual cause of the problem was that other processes consumed enough memory that there was not enough free memory to load the core image. Freeing up memory on the machine by stopping the memory hog processes fixed the problem.
I currently try to build a Debian package for the armhf (ARMv7) architecture, but I want the build script to recognize the architecture itself. The problem is, that I can not find the architecture, that APT uses to retrieve the package from a repository.
In my case, APT uses armhf, when it retrieves packages.
When I run uname -m, I get armv7 as a result. A grep -rn armhf /etc does not show any appearance of armhf, relevant for APT to choose from.
So, where can I get (Debian 9 (Stretch) or Armbian next) a reliable source for that information from the system that is independent of the architecture (my script should run also on i686, amd64, armel & arm64)?
The answer is
dpkg --print-architecture
This gives you the architecture Debian is selecting for packages. I'm not sure what happens on multi-architecture systems (i686 and amd64), but this can be separated quite easily.
I am trying to compile a program to put on a BeagleBone black, but im getting this error
when running the program on my board:
/lib/libc.so.6: version `GLIBC_2.17' not found
I made sure that i cross compiled for ARM (arm-linux-gnueabi-gcc).
On my desktop, I have EGLIBC 2.17-9.
What did i do wrong?
Had face the same problem.
Solved it by the following steps.
Downloaded "libc6_2.17-0ubuntu5.1_i386.deb"
sudo dpkg -i ipts libc6_2.17-0ubuntu5.1_i386.deb
sudo dpkg -i ipts libc6_2.17-0ubuntu5.1_i386.deb
Download 64 bit package from this site https://launchpad.net/ubuntu/raring/amd64/libc6/2.17-0ubuntu4
Install libc6 2.17 by the command ,
sudo dpkg -i libc6_2.17-0ubuntu4_amd64.deb
Cheers !
You don't have glibc 2.17 installed on your target board. You need to ensure that you have the SAME version of glibc (for ARM) installed on both the target board and on your build machine (your desktop). You can do this by either installing 2.17 on the target board or by figuring out what version you have installed there and installing that same version on your build machine (and linking with it).
This shell script worked for me: https://groups.google.com/forum/#!category-topic/beagleboard/oPq-Xt0TVdY
see the response from "A P" which is a script that installs a later version on the beaglebone black:
I am running a beaglebone black rev C with debian wheezy.
#!/bin/sh
echo "deb http://ftp.debian.org/debian sid main" >> /etc/apt/sources.list
apt-get update
apt-get -t sid install libc6 libc6-dev libc6-dbg
echo "Please remember to hash out sid main from your sources list. /etc/apt/sources.list"