Recently I upgraded Ubuntu to the 20.04 version.
Unfortunately, after the upgrade, the problems with Imagemagick appeared.
$ magick
magick: error while loading shared libraries: libIlmImf-2_2.so.22: cannot open shared object file: No such file or directory
The same errors with libIlmImf is returned when use identify or convert command.
As an inexperienced user of Ubuntu, I think I could mess something up with packages trying to solve it.
apt list --installed | grep magick
graphicsmagick/focal,now 1.4+really1.3.35-1 amd64 [installed,auto-removable]
imagemagick-6-common/focal-updates,focal-updates,focal-security,focal-security,now 8:6.9.10.23+dfsg-2.1ubuntu11.1 all [installed,automatic]
imagemagick-6.q16/focal-updates,focal-security,now 8:6.9.10.23+dfsg-2.1ubuntu11.1 amd64 [installed]
libgraphicsmagick-q16-3/focal,now 1.4+really1.3.35-1 amd64 [installed,auto-removable]
libmagickcore-6.q16-6-extra/focal-updates,focal-security,now 8:6.9.10.23+dfsg-2.1ubuntu11.1 amd64 [installed,automatic]
libmagickcore-6.q16-6/focal-updates,focal-security,now 8:6.9.10.23+dfsg-2.1ubuntu11.1 amd64 [installed,automatic]
libmagickwand-6.q16-6/focal-updates,focal-security,now 8:6.9.10.23+dfsg-2.1ubuntu11.1 amd64 [installed,automatic]
which magick
/usr/local/bin/magick
Grepping libIlmImf also returns different versions that are expected:
ls /usr/lib/x86_64-linux-gnu/ | grep libIlmImf
libIlmImf-2_3.so.24
libIlmImf-2_3.so.24.0.0
libIlmImf.a
libIlmImf.so
libIlmImfUtil-2_3.so.24
libIlmImfUtil-2_3.so.24.0.0
libIlmImfUtil.a
libIlmImfUtil.so
Does anyone encounter issues with Imagemagick after the upgrade? Do you have some suggestions that may help me?
As Mark Setchell wrote
Looks like your libIlmImf is one minor version newer than the one ImageMagick wants
Unfortunately, I could not install packages in lower versions because of dependencies and I did not try making a symlink.
But I get it running by downloading older packages from ubuntuupdates
libopenexr22
libilmbase
Then I copied these files to /usr/lib/x86_64-linux-gnu/ and now all commands: identify, convert and magick works good.
Thank you #mark-setchell! Symlink works in my case!
cd /usr/lib/x86_64-linux-gnu/
ln -s libIlmImf-2_3.so.24 libIlmImf-2_2.so.22
Related
The l4t-base:r32.2.1 base image (jetson) provided by NVIDIA does not have cuda binaries
Pytorch is looking for. I am unable to download source files from Jetpack 4.2.2 (specifically cuda-l4t-repo-10.x.x-arm64.deb) to include within docker build.
I am building a docker container for jetsons. I used the l4t image from NVIDIA, but it is missing some binaries pytorch is looking for (I understand you're supposed to mount some files for CUDA, but I don't want to). I therefore was going to install CUDA 10 directly into the container.
I am trying to download the source files for Jetpack 4.2.2. From what I have read, there should be a file, "cuda-repo-l4t-10-0-local-_arm64.deb". However, I only see
cuda-repo-cross-aarch64-10-0-local-10.0.326_1.0-1_all.deb and cuda-repo-ubuntu1804-10-0-local-10.0.326-410.108_1.0-1_amd64.deb.
I created an Ubuntu 18 container to run the SDK in. I run the below command and get the following files...
2019_06_23_2352-26660552-NVIDIA_Nomad_2019.2.19174.2352_Release_External-L4T.linux.deb,
libopencv-dev_3.3.1-2-gb3f86dcd5_amd64.deb,
Jetson_Linux_R32.2.1_aarch64.tbz2,
libopencv-python_3.3.1-2-gb3f86dcd5_amd64.deb
NVIDIA_VisionWorks_References.zip,
libopencv-samples_3.3.1-2-gb3f86dcd5_amd64.deb
NsightSystems-linux-public-2019.4.1.10-a76094a.deb
libopencv_3.3.1-2-gb3f86dcd5_amd64.deb
Tegra_Linux_Sample-Root-Filesystem_R32.2.1_aarch64.tbz2
libvisionworks-repo_1.6.0.500n_amd64.deb
cuda-repo-cross-aarch64-10-0-local-10.0.326_1.0-1_all.deb
libvisionworks-sfm-repo_0.90.4_amd64.deb
cuda-repo-ubuntu1804-10-0-local-10.0.326-410.108_1.0-1_amd64.deb
libvisionworks-tracking-repo_0.88.2_amd64.deb
devtools_docs.zip
sdkml3_jetpack_l4t_422_rev1_b30.json
sdkmanager --cli downloadonly --user $NV_USER \
--view live --host --logintype devzone --product Jetson --version 4.2 \
--targetos Linux --target $DEVICE_ID --flash all --license accept \
--downloadfolder /tmp/cuda_pkg
Desired results:
- download jetson jetpack ARM specific cuda packages during docker build
- all cuda binaries are available in container
instead of:
root#24081bcd996b:/usr/local/cuda-10.0/lib64# ls
libcudadevrt.a libcudart_static.a stubs
should look more like:
libOpenCL.so libcufft.so.10.0 libnppc.so libnppif_static.a libnpps.so.10.0.176
libOpenCL.so.1 libcufft.so.10.0.176 libnppc.so.10.0 libnppig.so libnpps_static.a
libOpenCL.so.1.0 libcufft_static.a libnppc.so.10.0.176 libnppig.so.10.0 libnvToolsExt.so
libOpenCL.so.1.0.0 libcufftw.so libnppc_static.a libnppig.so.10.0.176 libnvToolsExt.so.1
libaccinj64.so libcufftw.so.10.0 libnppial.so libnppig_static.a libnvToolsExt.so.1.0.0
libaccinj64.so.10.0 libcufftw.so.10.0.176 libnppial.so.10.0 libnppim.so libnvblas.so
libaccinj64.so.10.0.176 libcufftw_static.a libnppial.so.10.0.176 libnppim.so.10.0 libnvblas.so.10.0
libcublas.so libcuinj64.so libnppial_static.a libnppim.so.10.0.176 libnvblas.so.10.0.176
libcublas.so.10.0 libcuinj64.so.10.0 libnppicc.so libnppim_static.a libnvblas.so.10.0.480
libcublas.so.10.0.176 libcuinj64.so.10.0.176 libnppicc.so.10.0 libnppist.so libnvgraph.so
libcublas.so.10.0.480 libculibos.a libnppicc.so.10.0.176 libnppist.so.10.0 libnvgraph.so.10.0
libcublas_device.a libcurand.so libnppicc_static.a libnppist.so.10.0.176 libnvgraph.so.10.0.176
libcublas_static.a libcurand.so.10.0 libnppicom.so libnppist_static.a libnvgraph_static.a
libcudadevrt.a libcurand.so.10.0.176 libnppicom.so.10.0 libnppisu.so libnvrtc-builtins.so
libcudart.so libcurand_static.a libnppicom.so.10.0.176 libnppisu.so.10.0 libnvrtc-builtins.so.10.0
libcudart.so.10.0 libcusolver.so libnppicom_static.a libnppisu.so.10.0.176 libnvrtc-builtins.so.10.0.176
libcudart.so.10.0.176 libcusolver.so.10.0 libnppidei.so libnppisu_static.a libnvrtc.so
libcudart_static.a libcusolver.so.10.0.176 libnppidei.so.10.0 libnppitc.so libnvrtc.so.10.0
libcudnn.so libcusolver_static.a libnppidei.so.10.0.176 libnppitc.so.10.0 libnvrtc.so.10.0.176
libcudnn.so.7 libcusparse.so libnppidei_static.a libnppitc.so.10.0.176 stubs
libcudnn.so.7.6.3 libcusparse.so.10.0 libnppif.so libnppitc_static.a
libcudnn_static.a libcusparse.so.10.0.176 libnppif.so.10.0 libnpps.so
libcufft.so libcusparse_static.a libnppif.so.10.0.176 libnpps.so.10.0
You can locate the url in the sdkml3_jetpack_l4t_422_rev1_b30.json to download the debain files that you are looking for .
Hope this helps
I am trying to run this tshark command :
tshark -r $file -T fields -E separator=/t -e frame.number -e frame.time -e frame.protocols -e frame.len -e frame.interface_id -e frame.interface_name
I get this warning :
** (process:30955): WARNING **: 'frame.interface_name' isn't a valid field!
tshark: Some fields aren't valid
But I am able to see the field when I open the file in Wireshark ?
What is the right way to access the interface_name info?
I am using the following tshark version -
TShark 1.12.1 (Git Rev Unknown from unknown)
Copyright 1998-2014 Gerald Combs <gerald#wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.32.4, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), with libnl 3, with SMI 0.4.8, with c-ares 1.9.1, with Lua
5.2, without Python, with GnuTLS 2.12.20, with Gcrypt 1.5.0, with MIT Kerberos,
with GeoIP.
Running on Linux 3.16.7-cb2000v1, with locale en_US.UTF-8, with libpcap version
1.3.0, with libz 1.2.7.
Intel(R) Xeon(R) CPU E5-2640 v4 # 2.40GHz
Built using gcc 4.7.2.
I tried updating wireshark -
$ sudo apt-get install wireshark
Reading package lists... Done
Building dependency tree
Reading state information... Done
wireshark is already the newest version.
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
isc-dhcp-relay : Depends: isc-dhcp-common (= 4.2.2.dfsg.1-5+deb70u8) but 4.2.2.dfsg.1-5+deb70u8 is to be installed
isc-dhcp-server : Depends: isc-dhcp-common (= 4.2.2.dfsg.1-5+deb70u8) but 4.2.2.dfsg.1-5+deb70u8 is to be installed
libsnmp-perl : Depends: perl (>= 5.14.2-21+deb7u5) but 5.14.2-21+deb7u3 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
It says wireshark is already the newest version.
This is the linux OS details of the machine :
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
Which version of tshark are you using? Run tshark -v to check.
The frame.interface_name display filter is only available beginning with version 2.4.0, so maybe you have an older version of tshark in your %PATH%?
Note that you can check for the availability of any display filter on the Wireshark Display Filter Reference Page.
Build Errors unable to find jq.
Err http://deb.debian.org jessie/main amd64 Packages
404 Not Found
Err http://deb.debian.org jessie-updates/main amd64 Packages
404 Not Found
Fetched 723 kB in 2s (357 kB/s)
W: Failed to fetch http://deb.debian.org/debian/dists/jessie/main/binary-amd64/Packages 404 Not Found
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/main/binary-amd64/Packages 404 Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
$ apt-get install jq
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package jq
ERROR: Job failed: exit code 1
#codinghaus mentioned in another thread:
This is due to the fact that
as Wheezy and Jessie have been integrated into the archive.debian.org structure recently, we are now removing all of Wheezy and all non-LTS architectures of Jessie from the mirror network starting today.
A solution (according to https://github.com/debuerreotype/docker-debian-artifacts/issues/66#issuecomment-476616579) is to add the following command into your Dockerfile before calling any apt-get update when using debian:jessie.
RUN sed -i '/jessie-updates/d' /etc/apt/sources.list # Now archived
This will remove the jessie-updates repository (which now causes the 404) from sources.list.
FROM debian:jessie
RUN sed -i '/jessie-updates/d' /etc/apt/sources.list # Now archived
RUN apt-get update
CMD /bin/sh
Just place this line before your apt-get commands in your Dockerfile:
RUN echo "deb http://deb.debian.org/debian jessie main" > /etc/apt/sources.list
Debian removed some url for old packages which is causing this issue. The line fixes the repository to refer to.
I had the same problem today. I believe yours is related to Jessie being removed from Debian (see: https://twitter.com/debian/status/1109080168318926851?s=12).
I upgraded php in Dockerfile to php:7.1.27-apache-stretch and it worked.
Maybe, the third party import that you are doing is not able to refer to the debian jessie, so changing ftp.debian.org to http://ftp.us.debian.org might make it work. If you are not referring to this directly, try upgrading or downgrading the imported versions, if removing them is not the option.
In my case, i was using:
FROM docker.***.com/node:10
downgrading the node from 10 to 8, kicked off the job successfully.
I am trying to install 32-bit packages on official alpine docker images but whenever I do apk add libcurl for example it install 64-bit version of libcurl whereas I want to install 32-bit package.
Any thoughts how to do the same on Alpine Linux 3.7?
Actually, only one file defines which packages take from alpine repos. It is /etc/apk/arch:
# cat /etc/apk/arch
x86_64
Its value shows which packages we should take from our alpine repos:
# cat /etc/apk/repositories
http://dl-cdn.alpinelinux.org/alpine/v3.7/main
http://dl-cdn.alpinelinux.org/alpine/v3.7/community
So, we can make a trick here. We can "switch" alpine to get x86 packages from the repos:
/ # echo "x86" > /etc/apk/arch
/ # apk add --no-cache libcurl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86/APKINDEX.tar.gz
(1/12) Replacing musl (1.1.18-r2 -> 1.1.18-r2)
(2/12) Replacing busybox (1.27.2-r8 -> 1.27.2-r8)
Executing busybox-1.27.2-r8.post-upgrade
(3/12) Replacing alpine-baselayout (3.0.5-r2 -> 3.0.5-r2)
Executing alpine-baselayout-3.0.5-r2.pre-upgrade
Executing alpine-baselayout-3.0.5-r2.post-upgrade
(4/12) Replacing libressl2.6-libcrypto (2.6.3-r0 -> 2.6.3-r0)
(5/12) Replacing libressl2.6-libssl (2.6.3-r0 -> 2.6.3-r0)
(6/12) Replacing zlib (1.2.11-r1 -> 1.2.11-r1)
(7/12) Replacing apk-tools (2.8.2-r0 -> 2.8.2-r0)
(8/12) Replacing scanelf (1.2.2-r1 -> 1.2.2-r1)
(9/12) Replacing musl-utils (1.1.18-r2 -> 1.1.18-r2)
(10/12) Installing ca-certificates (20171114-r0)
(11/12) Installing libssh2 (1.8.0-r2)
(12/12) Installing libcurl (7.57.0-r0)
Executing busybox-1.27.2-r8.trigger
Executing ca-certificates-20171114-r0.trigger
OK: 5 MiB in 14 packages
Since you're using Docker, why not use the 32-bit alpine image?
$ docker run --rm -it i386/alpine
/ # apk add --no-cache libcurl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86/APKINDEX.tar.gz
...
More info: Architectures other than amd64?
I am attempting to rebuild my development/test environment on a new laptop running windows7 32 bit. imageMagick is one of the modules I had installed in an (ancient) version on my old laptop. I have downloaded and installed perl from dwimperl, which is v5.14.2 and had a couple modules install, and several did not.
cpanm Image::Magick - failed
cpanm DB_File - failed
cpanm Time::HiRes - failed
I searched around and found a discussion on magick failing to install on v5.12, but couldn't tell if that was supposed to have been fixed, or if I need to attempt to recreate the fix discussed for 5.12
should I try installing perl from Strawberry? looks like it is a little newer v5.18 ?
is there something I can tweak and re-run cpan installs?
I installed the binaries from imagemagick, from Link first, then cpan again, and cpan still fails....
This is the top part of the build log down to where it really goes south and starts kicking out errors:
cpanm (App::cpanminus) 1.6941 on perl 5.014002 built for MSWin32-x86-multi-thread
Work directory is C:\Users\dtbaker/.cpanm/work/1377281741.8420
You have make C:\Dwimperl\c\bin\dmake.exe
You have LWP 6.03
Falling back to Archive::Tar 1.80
Searching Image::Magick on cpanmetadb ...
--> Working on Image::Magick
Fetching http://www.cpan.org/authors/id/J/JC/JCRISTY/PerlMagick-6.86.tar.gz
-> OK
Unpacking PerlMagick-6.86.tar.gz
Entering PerlMagick-6.86
META.yml/json not found. Creating skelton for it.
Configuring PerlMagick-6.86
Running Makefile.PL
################################### WARNING! ###################################
# It seems that you are trying to install Perl::Magick on a MS Windows box with
# perl + gcc compiler (e.g. strawberry perl), however we cannot find ImageMagick
# binaries installed on your system.
#
# Please check the following prerequisites:
#
# 1) You need to have installed ImageMagick Windows binaries from
# http://www.imagemagick.org/script/binary-releases.php#windows
#
# 2) We only support dynamic (DLL) ImageMagick binaries
# note: it is not possible to mix 32/64-bit binaries of perl and ImageMagick
#
# 3) During installation select that you want to install ImageMagick's
# development files (libraries+headers)
#
# 4) You also need to have ImageMagick's directory in your PATH
# note: we are checking the presence of convert.exe and/or identify.exe tools
#
# 5) You might need Visual C++ Redistributable Package installed on your system
# see instructions on ImageMagick's Binary Release webpage
#
# We are gonna continue, but chances for successful build are very low!
################################################################################
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lMagickCore-6.Q16
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.62)
Building and testing Image-Magick-6.86
cp Magick.pm blib\lib\Image\Magick.pm
AutoSplitting blib\lib\Image\Magick.pm (blib\lib\auto\Image\Magick)
C:\Dwimperl\perl\bin\perl.exe C:\Dwimperl\perl\lib\ExtUtils\xsubpp -typemap C:\Dwimperl\perl\lib\ExtUtils\typemap -typemap typemap Magick.xs > Magick.xsc && C:\Dwimperl\perl\bin\perl.exe -MExtUtils::Command -e mv -- Magick.xsc Magick.c
gcc -c -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"6.86\" -DXS_VERSION=\"6.86\" "-IC:\Dwimperl\perl\lib\CORE" -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
Magick.xs:60:31: error: magick/MagickCore.h: No such file or directory
Magick.xs:167: error: expected specifier-qualifier-list before 'MagickRealType'
Magick.xs:188: error: expected specifier-qualifier-list before 'ImageInfo'
Magick.xs:210: error: 'MagickNoiseOptions' undeclared here (not in a function)
however we cannot find ImageMagick binaries installed on your system.
Is ImageMagick is in your path, as recommanded in the 4) point? Open cmd.exe and type convert -v or convert.exe -v. If you don't see informations about Image Magick (Windows have a built-in convert command), it is very likely you have to add it to your path.
You also have to check points 1), 3), and 5). After that try again to run installation process through cpanm.
Trying to install for Citrus Perl, I discovered on debugging through the Perl part of the install that the mingw64 install had not included 'pexports.exe'. Downloading that from https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/
and placing it in the mingw64 directory was necessary to solve the problem of a long list of library export symbols not found.
Prior to that I had also set the environment variables CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH to point to the "include" directory of the ImageMagick install include directory in C:\Program Files (x86). (When you install ImageMagick you should check the box to install also for Strawberry Perl.)