I am trying to run Quartus 13.0 in the following machine:
parrot 4.18.0-parrot10-amd64 #1 SMP Debian 4.18.10-1parrot10 (2018-10-06) x86_64 GNU/Linux.
I have finished installing Quartus 13.0 and when I try to execute it I get this error:
quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
I have read all the related questions in stack overflow and other websites but no one worked for me.
When looking for that file, I found it. I have tried to do a hard link but it doesn't work either. Search results:
┌─[pepbd#parrot]─[~]
└──╼ $ls -ld $(locate -r libpng.*\.so.*)
lrwxrwxrwx 1 root root 19 nov 19 17:09 /usr/lib/x86_64-linux-gnu/libpng16.so.16 -> libpng16.so.16.34.0
-rw-r--r-- 1 root root 210864 jul 10 13:17 /usr/lib/x86_64-linux-gnu/libpng16.so.16.34.0
-rw-r--r-- 1 root root 18272 oct 14 21:59 /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libpng_plugin.so
I had the same problem with Quartus Prime 18 on Ubuntu. This worked for me (run as sudo):
wget -q -O /tmp/libpng12.deb http://mirrors.kernel.org/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1_amd64.deb \
&& dpkg -i /tmp/libpng12.deb \
&& rm /tmp/libpng12.deb
Related
I'm unsure about some small obscure details that I worry will have large effects. On my Raspbian Debian 11 running on a Raspberry Pi, sudo apt update && sudo apt full-upgrade only updates my libxml2 library to version 2.9.10, no further. However, I need version 2.9.14 for the security patches contained within. With help from this question (thank you Esther!), I decided to compile version 2.9.14 from source. Everything went well, and the library was placed into /usr/local/lib. I then updated ldconfig by following this answer. However, although that should have made Debian use the new 2.9.14 version, apt-cache policy libxml2 still shows:
libxml2:
Installed: 2.9.10+dfsg-6.7+deb11u2
Candidate: 2.9.10+dfsg-6.7+deb11u2
Version table:
*** 2.9.10+dfsg-6.7+deb11u2 500
500 http://raspbian.raspberrypi.org/raspbian stable/main armhf Packages
100 /var/lib/dpkg/status
I think I know why this is. If I was installing a never-before-seen library, everything might have worked properly. However, since I now have a second libxml2 library without removing the 1st, any time the system needs to use libxml2, the search first reaches /usr/lib/arm-linux-gnueabihf where the old libxml2 is, so the system finds the old version, is satisfied, and so stops searching before finding the new version.
For context before I continue:
(link to below but in color: https://i.stack.imgur.com/OJLJW.png)
pi#fuelightcontrol:~ $ cd /usr/lib/arm-linux-gnueabihf/
pi#fuelightcontrol:/usr/lib/arm-linux-gnueabihf $ ls -l | grep libxml2
lrwxrwxrwx 1 root root 17 May 15 14:58 libxml2.so.2 -> libxml2.so.2.9.10
-rw-r--r-- 1 root root 1510312 May 15 14:58 libxml2.so.2.9.10
pi#fuelightcontrol:/usr/lib/arm-linux-gnueabihf $ cd /usr/local/lib
pi#fuelightcontrol:/usr/local/lib $ ls -l
total 12120
drwxr-xr-x 3 root root 4096 Jun 14 18:17 cmake
-rw-r--r-- 1 root root 7145994 Jun 14 18:17 libxml2.a
-rwxr-xr-x 1 root root 944 Jun 14 18:17 libxml2.la
lrwxrwxrwx 1 root root 17 Jun 14 18:17 libxml2.so -> libxml2.so.2.9.14
lrwxrwxrwx 1 root root 17 Jun 14 18:17 libxml2.so.2 -> libxml2.so.2.9.14
-rwxr-xr-x 1 root root 5242072 Jun 14 18:17 libxml2.so.2.9.14
drwxr-xr-x 2 root root 4096 Jun 14 18:17 pkgconfig
drwxr-xr-x 3 root root 4096 Jun 13 21:43 python3.9
-rw-r--r-- 1 root root 205 Jun 14 18:17 xml2Conf.sh
pi#fuelightcontrol:/usr/local/lib $
The question is, what would be the best way to go about fixing the problem of the old version still being used by apt-cache policy libxml2 and other programs? I could:
Just delete /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 (the old one) and its symbolic link, so the system keeps searching past that point and eventually finds /usr/local/lib/libxml2.so.2.9.14 (the new one). However, something feels... off about having my libraries scattered around in different directories. My gut tells me to keep them in one place. Also, see paragraph below the next list item.
I could delete /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 (the old one) and its symbolic link, then move the new version into /usr/lib/arm-linux-gnueabihf to replace the old version. However, there's more libxml2 related files and 1 more symbolic link in /usr/local/lib that are not present in /usr/lib/arm-linux-gnueabihf. Do I need to move those too, or should I just move libxml2.so.2.9.14 and one (both?) of the symbolic links? If only 1 link, which?
Should I delete the files left behind after I move the required ones over? Also, see paragraph below.
What concerns me about deleting anything is if some other script comes looking for libxml2.2.9.10, can't find it, and fails. I don't know how to tell the rest of the programs that libxml2's filename is different now. I suppose both options 1 and 2 might work, but is one option a cleaner, smarter idea? I'm trying to save myself some work in the future.
Sorry this is such a small silly question. Thank you for your help!
Edit: After making backups of both directories, I tried option 1 first, then option 2. Neither changed the output of apt-cache policy libxml2 - it still says I have libxml2 2.9.10 installed, even though I deleted /usr/lib/arm-linux-gnueabihf/libxml2.so.2.9.10 and its symbolic link, rebooted, and ran sudo apt update
Here's how I updated ldconfig (same as the second link), to clear up loose ends. The link to /usr/local/lib was done for me already, which was nice.
Link to screenshot of below but in color: https://i.stack.imgur.com/7w6XR.png
pi#fuelightcontrol:/etc $ ls -l ld.so.conf
ld.so.conf ld.so.conf.d/
pi#fuelightcontrol:/etc $ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
pi#fuelightcontrol:/etc $ ls -l ld.so.conf.d
total 16
-rw-r--r-- 1 root root 12 Dec 1 2021 00-vmcs.conf
-rw-r--r-- 1 root root 109 May 14 2019 arm-linux-gnueabihf.conf
-rw-r--r-- 1 root root 41 Jun 25 2018 fakeroot-arm-linux-gnueabihf.conf
-rw-r--r-- 1 root root 44 Jun 14 19:08 libc.conf
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib
pi#fuelightcontrol:/etc $ sudo ldconfig
pi#fuelightcontrol:/etc $ sudo ldconfig /usr/local/lib
pi#fuelightcontrol:/etc $ sudo ldconfig -n /usr/local/lib
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/00-vmcs.conf
/opt/vc/lib
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/arm-linux-gnueabihf.conf clear
# Multiarch support
/usr/local/lib/arm-linux-gnueabihf
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
cat: clear: No such file or directory
pi#fuelightcontrol:/etc $ cat ld.so.conf.d/fakeroot-arm-linux-gnueabihf.conf
/usr/lib/arm-linux-gnueabihf/libfakeroot
pi#fuelightcontrol:/etc $
I try to set up FastRTPS inside a docker container. I wrote a Dockerfile which builds FastRTPS and it's dependencies from source and installs the libraries and delivered examples. But the examples do not work:
/opt# /usr/local/examples/C++/HelloWorldExample/bin/HelloWorldExample
/usr/local/examples/C++/HelloWorldExample/bin/HelloWorldExample: error while loading shared libraries: libfastrtps.so.1: cannot open shared object file: No such file or directory
As these library was built in this container and automatically installed, it must be somewhere and they are here:
root#6e544f0699cf:/opt# ls -la /usr/local/lib/
total 9196
drwxr-xr-x 1 root root 4096 Mar 26 22:02 .
drwxr-xr-x 1 root root 4096 Mar 26 22:02 ..
drwxr-xr-x 3 root root 4096 Mar 26 22:00 cmake
drwxr-xr-x 3 root root 4096 Mar 26 22:00 foonathan_memory
lrwxrwxrwx 1 root root 15 Mar 26 22:00 libfastcdr.so -> libfastcdr.so.1
lrwxrwxrwx 1 root root 20 Mar 26 22:00 libfastcdr.so.1 -> libfastcdr.so.1.0.12
-rw-r--r-- 1 root root 99504 Mar 26 22:00 libfastcdr.so.1.0.12
lrwxrwxrwx 1 root root 16 Mar 26 22:02 libfastrtps.so -> libfastrtps.so.1
lrwxrwxrwx 1 root root 21 Mar 26 22:02 libfastrtps.so.1 -> libfastrtps.so.1.10.0
-rw-r--r-- 1 root root 8133952 Mar 26 22:01 libfastrtps.so.1.10.0
-rw-r--r-- 1 root root 1158048 Mar 26 22:00 libfoonathan_memory-0.6.2.a
drwxrwsr-x 3 root staff 4096 Mar 26 21:37 python3.7
It is also possible to look into this library # nm -D /usr/local/lib/libfastrtps.so.1.
But the output of ldconfig is a bit strange:
# ldconfig -v | grep /usr/local/lib
ldconfig: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
ldconfig: Path `/lib/x86_64-linux-gnu' given more than once
ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
ldconfig: /lib/x86_64-linux-gnu/ld-2.28.so is the dynamic linker, ignoring
/usr/local/lib:
Here I expected the libraries listed but they are not.
How to fix that?
EDIT 1
some extractions from the make output while building FastRTPS:
...
-- Installing: /usr/local/lib/libfastrtps.so.1.10.0
-- Installing: /usr/local/lib/libfastrtps.so.1
-- Installing: /usr/local/lib/libfastrtps.so
...
-- Installing: /usr/local/examples/C++/HelloWorldExample/bin/HelloWorldExample
-- Set runtime path of "/usr/local/examples/C++/HelloWorldExample/bin/HelloWorldExample" to ""
Why the runtime path is set to "" - nothing?
The last edit led to the issue and also to the solution.
CMake removes the RPATH. In case of the usage within a docker container, this stripping makes no sense and can be turned off as described in this post by adding this argument to the CMake configuration call:
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE
At the end my Dockerfile looks like this:
FROM fastrtps-core
WORKDIR /opt
RUN git clone https://github.com/eProsima/Fast-RTPS.git && \
export LDFLAGS="-Wl,--copy-dt-needed-entries" && \
mkdir build && \
cd build && \
cmake ../Fast-RTPS/examples \
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE && \
cmake --build . --target install -j 16 && \
cd /opt && \
rm -rf build Fast-RTPS
Now the install-step output shows the correct runtime-path setting:
-- Installing: /usr/local/examples/C++/HelloWorldExample/HelloWorldExample
-- Set runtime path of "/usr/local/examples/C++/HelloWorldExample/HelloWorldExample" to "/usr/local/lib"
I'm using Fedora 25.
I have a binary that needs multiple libraries. The binary can't find libRblas.so:
$ ldd XPore-Engine | less | grep not
libvtkRenderingAnnotation.so.1 => /usr/lib64/vtk/libvtkRenderingAnnotation.so.1 (0x00007fac12563000)
libRblas.so => not found
libRblas.so => not found
libRblas.so => not found
The library path is properly configured with a .conf file:
$ cat /etc/ld.so.conf.d/R-x86_64.conf
/usr/lib64/R/lib
$ ll /usr/lib64/R/lib
lrwxrwxrwx. 1 root root 11 dic 16 20:46 libopenblas.so.0 -> libRblas.so
lrwxrwxrwx. 1 root root 27 oct 31 21:16 libRblas.so -> /usr/lib64/libopenblas.so.0
-rwxr-xr-x. 1 root root 1989312 oct 31 21:16 libRlapack.so
-rwxr-xr-x. 1 root root 178856 oct 31 21:16 libRrefblas.so
-rwxr-xr-x. 1 root root 2911536 oct 31 21:16 libR.so
And I load the configuration with ldconfig:
$ ldconfig -v | grep libRblas
libopenblas.so.0 -> libRblas.so
However, after executing ldd again it returns the same output saying that libRblas.so wasn't found.
How can I fix this?
I've found a workaround provided by Tom in the Read Hat Bugzilla bug-tracking system at https://bugzilla.redhat.com/show_bug.cgi?id=1404662.
Yeah, so it looks like while R is perfectly happy using libRblas.so as a > symlink to libopenblas.so.0, externally, nothing else is.
The speedup from using openblas is significant, so the fix is to build a copy of openblas that has the libRblas.so filename and soname, and use that instead of the symlink. I have a new build of openblas going which adds this, then I'll do a new round of R builds that depend on it.
As a temporary workaround, you can run (as root):
rm -f /usr/lib64/R/lib/libRblas.so
mv /usr/lib64/R/lib/libRrefblas.so /usr/lib64/R/lib/libRblas.so
That will restore the unoptimized libRblas.so that R provides.
Oh, and run /sbin/ldconfig (as root) after moving libRrefblas.so so that the ldcache is updated.
When I try to do a manual source install of some software on NixOS 15.09, I get (sh -x is to get an exec log):
[nix-shell:/tmp/nix-shell-es/EventStore-oss-v3.5.0-src]$ sh -x scripts/build-js1/build-js1-linux.sh werror=no
...
+ CXXFLAGS=-fPIC
+ make x64.release werror=no
PYTHONPATH="/tmp/nix-shell-es/EventStore-oss-v3.5.0-src/scripts/build-js1/v8/tools/generate_shim_headers:" \
GYP_GENERATORS=make \
build/gyp/gyp --generator-output="out" build/all.gyp \
-Ibuild/standalone.gypi --depth=. \
-Dv8_target_arch=x64 \
-Dv8_optimized_debug=0 \
-S.x64.release -Dv8_enable_backtrace=1 -Dwerror='' -Darm_fpu=default -Darm_float_abi=default
/bin/sh: build/gyp/gyp: /bin/bash: bad interpreter: No such file or directory
Makefile:389: recipe for target 'out/Makefile.x64.release' failed
make: *** [out/Makefile.x64.release] Error 126
And indeed there is no bash program in /bin/
[nix-shell:/tmp/nix-shell-es/EventStore-oss-v3.5.0-src]$ ls -la /bin/
total 12
drwxr-xr-x 2 root root 4096 Feb 24 12:25 .
drwxr-xr-x 18 root root 4096 Feb 24 12:16 ..
lrwxrwxrwx 1 root root 63 Feb 24 12:25 sh -> /nix/store/l80ddf18bbig2icv6cmgjfws9a2vm3jj-bash-4.3-p42/bin/sh
However when I inspect the script I dont see any mention of it so it must be some subprogram looking for it.
As an aside, I imagine that's probably why the script wisely starts with #!/usr/bin/env bash and not the direct location of bash.
Anyone knows a blessed way to deal with this ?
one has to run patchShebangs ./scripts/build-js1/build-js1-linux.sh on files coming from source when they are not in the store and we want to execute them.
I have read the Theos/Setup on the iPhoneDev Wiki.
I have installed Theos into /var/theos (private/var/theos) and have copied in the iPhone8.1.sdk into /var/theos/sdks/iPhone8.1.sdk:
iPhone:/var/theos/sdks root# ls -al
total 0
drwxr-xr-x 3 root admin 102 Nov 7 08:11 ./
drwxr-xr-x 9 root admin 374 Nov 7 07:58 ../
drwxrwxr-x 5 root admin 306 Nov 7 08:01 iPhoneOS8.1.sdk/
I have fixed the issues with perl/rsync not being compiled for arm64 by following the instructions
I created a tool:
$THEOS/bin/nic.pl
....
iPhone:~/Work/test root# ls
Makefile control main.mm theos#
However, when I make, I get the following error:
iPhone:~/Work/test root# make
/var/theos/makefiles/common.mk:116: *** The "iphone" target is not supported on the "iphone" platform. Stop.
What am I doing wrong? Or is this a problem with the 8.1 sdk?
Following the article at http://sharedroutine.com/?p=11 got it working for me.
I symlinked /var/theos/makefiles/platform/Darwin-arm to /var/theos/makefiles/platform/Darwin-arm64 and forgot to symlink /var/theos/makefiles/targets/Darwin-arm to /var/theos/makefiles/targets/Darwin-arm64.
ln -s /var/theos/makefiles/targets/Darwin-arm /var/theos/makefiles/targets/Darwin-arm64
ln -s /var/theos/makefiles/platform/Darwin-arm /var/theos/makefiles/platform/Darwin-arm64
Your paths may be different.