I can't load packages in R because the file libpq.5.dylib is not in /usr/lib/libpq.5.dylib. It is in /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib
I tried this line: sudo ln -s /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib /usr/lib/libpq.5.dylib but I get this response: ln: /usr/lib/libpq.5.dylib: Operation not permitted
What can I do to get the file in /usr/lib/libpq.5.dylib without causing issues? This solution suggests that I may face problems down the line so I don't understand what to do.
You really don't want it in /usr/lib. Apple declared that as off-limits, and on newer macOS versions it lives on a read-only volume. Unless you're willing to go into recovery mode and manually tamper with the volume (and possibly repeat that on future OS updates), this is not the way to go.
Instead, let's address the core issue:
Dynamic libraries on macOS embed their own install path inside the binary, and the linker copies that into binaries linking against them. This information can be changed with install_name_tool (see man install_name_tool).
Examine the install name of the dylib:
otool -l /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib | fgrep -A2 LC_ID_DYLIB
If the printed path already points to the dylib itself (or a path that is symlinked to it), use this path as [new_path] below, and skip step 2.
If the dylib's install name does not point back to itself, run this:
sudo install_name_tool -id /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib
And use /usr/local/Cellar/libpq/13.0/lib/libpq.5.dylib for [new_path] below.
For binaries that link against the dylib, run:
sudo install_name_tool -change /usr/lib/libpq.5.dylib [new_path] [path_to_binary]
I had the same issue building a container through docker for API use : RPostgres was installed but the library couldn't load, same error message.
Since I had installed Postgres on my machine, I figure the problem was worked around therefore I had no such message on local ; but here's how I solved this in my dockerfile, 100% verified on a machine with nothing related to R installed :
RUN apt-get update && apt-get install libpq5 -y
So executing apt-get update && apt-get install libpq5 -y on your terminal should do the trick. Light and efficient.
It tried to load libpq.5.dylib from the symlink /opt/homebrew/opt/postgresql/lib/libpq.5.dylib but could not find the file, so you need to update it:
# TODO: get this from the error, after "Library not loaded:"
SYMLINK_PATH="/opt/homebrew/opt/postgresql/lib/libpq.5.dylib"
# TODO: find this in your machine. The version maybe different than mine
DESTINATION_PATH="/opt/homebrew/opt/postgresql/lib/postgresql#14/libpq.5.dylib"
sudo mv $SYMLINK_PATH $SYMLINK_PATH.old
sudo ln -s $DESTINATION_PATH $SYMLINK_PATH
Related
As sometime I am trying to compile a full version (with all options) of rsync on MacOS (please, do not ask why I want to do it - if you can help me clear and directly, thank you so much. Otherwise, do not waste your time).
I found a really helpful script made by "junsionzhang" (https://gist.github.com/junsionzhang), which in my option is simple and direct. Thank you junsionzhang!
Even being a good script, clear, step-by-step, there are some steps that does not work for me (and I tried a lot and for a while).
Here is the script (at Oct, 16, 2022):
#Compile rsync 3.0.7
#Follow these instructions in Terminal on both the client and server to download and compile rsync 3.0.7:
#Download and unarchive rsync and its patches
cd ~/Desktop
curl -O http://rsync.samba.org/ftp/rsync/src/rsync-3.1.2.tar.gz
tar -xzvf rsync-3.1.2.tar.gz
rm rsync-3.1.2.tar.gz
curl -O http://rsync.samba.org/ftp/rsync/src/rsync-patches-3.1.2.tar.gz
tar -xzvf rsync-patches-3.1.2.tar.gz
rm rsync-patches-3.1.2.tar.gz
cd rsync-3.1.2
#Apply patches relevant to preserving Mac OS X metadata
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/hfs-compression.diff
#Configure, make, install
./prepare-source
./configure
make
sudo make install
#Verify your installation
/usr/local/bin/rsync --version
#By default, rsync will be installed in /usr/local/bin.
#If that isn't in your path, you will need to call your new version of rsync by its absolute path (/usr/local/bin/rsync).
The three patches lines does not work for me. After patching the fileflags, the rsync patched can not me "prepared", and of course, not be configured. The others, crtimes.diff and hfs-compression.diff, does not exist on the TAR package.
So, questions:
Trying to compile the 3.2.6 version os MacOS Big Sur (11.7), what do I need and which is the right/correct way and steps to patch, update and have the "correct"version?
How do I (correctly) compile and install the all the libraries to have a real full rsync version, with all features available (ACL support, Xattr support, xxhash, zstd, lz4, openssl crypto, and so on...)?
I would like to update and contribute to a new "junsionzhang" script version, making options to install a simple/standard version (rsync only) and options to install the libraries and choose for a "more complete" version, and help another Mac users and the community. How can I make this bash script?
How to install gawk, mawk, nawk, awk ( and where from (what are the differences): gawk, mawk, nawk?
Some libraries I already have installed (which I do not know if I did them right) seems to be outdated. How to I update them?
When running "./prepare-source", i get this: "make: Nothing to be done for `conf'.". Does this is right?
Thank you all! I really appreciate for all help I can get!
Completely untested (I don't run MacOS).
URLs to access the source code:
Source Version Tarballs: https://rsync.samba.org/ftp/rsync/src/
Git repository: https://github.com/WayneD/rsync
might need these pre-requisites (from INSTALL.md):
brew install automake
brew install xxhash
brew install zstd
brew install lz4
brew install openssl
code to download and extract (to ~/Desktop/rsync-3.2.6):
# Download the relevant version of Rsync and the same version of
# Rsync patches, extract them and apply the "suggested"
# patches from the original script:
cd ~/Desktop
# Rsync
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-3.2.6.tar.gz
tar -xzvf rsync-3.2.6.tar.gz
rm rsync-3.2.6.tar.gz
# Patches
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-patches-3.2.6.tar.gz
tar -xzvf rsync-patches-3.2.6.tar.gz
rm rsync-patches-3.2.6.tar.gz
apply the "suggested" patches, light the blue touch paper and stand back:
cd ~/Desktop/rsync-3.2.6
# Apply patches relevant to preserving Mac OS X metadata
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/hfs-compression.diff
# Configure, make, install
./prepare-source
./configure
make
sudo make install
# Verify your installation
/usr/local/bin/rsync --version
I am attempting to utilize the rocker/r-apt image which enables R binary installs.
My 72 Minute Docker Build using the r-base image could use some help...
My file looks like this.
FROM container.registry/rocker/r-apt:bionic
RUN apt-get update
Couple of notes. My company uses an internal registry, so i've downloaded the image from
https://hub.docker.com/r/rocker/r-apt
and pushed it to my local container registry.
When I try and build the Docker container it gives me this error.
UPDATE - Full Error message
/deb.debian.org/debian testing InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
I can post a more detailed error message when the internet on my other computer returns.
I realize now that bionic is the Ubuntu distro. r-base uses a debian base from what I can tell.
My big question..what am I doing wrong to get this rocker/r-apt image to run correctly and still allow me to use apt-get to install a number of things, include the cran-r packages that its supposed to enable.
I am following this post by datawookie.
https://datawookie.netlify.app/blog/2019/01/docker-images-for-r-r-base-versus-r-apt/
UPDATE
My new big question... should i be pointing at deb.debian.org/debian for apt-get?
I would suggest to use rocker/r-ubuntu instead of rocker/r-apt (which predates it). I am the man behind the curtain for both.
Within Rocker we have containers based on Debian, and containers based on Ubuntu, and containers based on Debian now that will likely be based on Ubuntu in the future. In short, "it's complicated" but that is in part ... because we have so darn many containers already.
The source for background information is still our R Journal paper (shortcut to pdf).
Success!!! So the R-Ubuntu 20.04 appears to be working like a charm.
My outcome of decreasing the build time of my R application has worked.
72 Minutes is now 4 Minutes
This is important because our applications run in CI/CD pipelines and so a 72 minute build is extremely annoying. Not to mention consumes lots of resources to compile code.
It looks like all my issues were related to my organizations Nexus Repository.
Once we downloaded the R-Ubuntu, we had to rebuild it from the GIT Repo to utilize our internal Ubuntu Image. That fixed 1 problem.
Then I had to import the Michael Rutter Repo as a source and update that to utilize the internal repository.
The one issue that might not be apparent is that the DockerFile has to have the apt-get update and installs in the correct order. I do not recall if the source image had all this, but I'll post the order here.
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
&& apt-get install -y gnupg2 \
&& apt-get install -y --no-install-recommends \
dialog \
software-properties-common \
ed \
less \
locales \
vim-tiny \
wget \
ca-certificates
So once all that was setup it worked like magic.
I have a package that previously only targeted RPM based distros for which I am now building .deb packages for Debian based distros.
The aim is to simulate a test installation from user-space that is isolated from the system you are building on. It may be multi-user and you do not want to require root access just to build the software. Many of our tests simulate the installation directory structure already. This is for the next step up to simulate an actual installation using packages built.
For the RPM packages I was able to create test installations using:
WSDIR=/where/I/want/my/tests/to/run
rpmdb --initdb --dbpath "$WSDIR"/rpmdb
rpm --relocate /opt="$WSDIR"/opt --dbpath $WSDIR/rpmdb -i <package>.rpm
The equivalent in the Debian world is something like:
dpkg --force-not-root --admindir=$WSDIR/dpkg --root=$WSDIR/install --install "$DEB"
However, I am stuck over the equivalent to the rpmdb --initdb step.
Note that I can just unpack the archive using:
dpkg-deb -x "$DEB" $WSDIR/install
But I would prefer to be closer to how a real package is installed.
Also I don't think this will run preinstall and postinstall scripts.
Similar questions have suggested using deboostrap to create a chroot environment but this creates a complete new installation. As well as being overkill it is too slow for an automated test. I intend to use this for quick tests of the installation package prior to further testing in actual test environments.
My experiments so far:
(cd $WSDIR/dpkg && mkdir alternatives info parts triggers updates)
cp /var/lib/dpkg/status $WSDIR/dpkg/status
have at best resulted in:
dpkg: error: unable to access dpkg status area: No such file or directory
which does not indicate clear what is wrong.
So how do you create a dpkg admin directory?
Cross posted as https://superuser.com/questions/1271145/how-do-you-create-a-dpkg-admin-directory
Update 24/11/2017
I've tried copying using the dpkg dir from an environment created by [cowdancer][1] (which uses deboostrap under the hood) or copying the real one from /var/lib/dpkg but I still get the same error message so perhaps the error (and/or the --admindir option) doesn't mean quite what I think it means.
Note that:
sudo dpkg --force-not-root --root=$WSDIR/install --admindir=/var/lib/dpkg --install "$DEB"
does work. So it is something to do with the admin dir.
I've also retitled the question as "How do you create a dpkg admin directory" is interesting question but the answer is not necessarily the solution to my problem.
The minimal way to create a dpkg database is something like this:
$ mkdir -p db/{updates,info}
$ touch db/{status,diversions,statoverride}
If you want to use that as non-root, currently the best way is to use fakeroot.
$ mkdir -p fsys
$ PATH=/sbin:/usr/sbin:$PATH fakeroot dpkg --log=/dev/null --admindir=db --instdir=fsys -i pkg.deb
But take into account that passing --root after --admindir or --instdir will reset those paths, which is I think the problem you have been having here.
Also using sudo and --force-not-root does not make much sense? :) And is definitely less confined than using just fakeroot. In the near future it will be possible to run dpkg fully unprivileged in some local tree.
I eventually found an answer for this. Thanks to Guillem Jover for some of this.
Pasting a copy of it here:
mkdir fake
mkdir fake/install
mkdir -p fake/dpkg/info
mkdir -p fake/dpkg/updates
touch fake/dpkg/status
PATH=/sbin:/usr/sbin:$PATH fakeroot dpkg --force-script-chrootless --log=`pwd`/fake/dpkg.log --root=`pwd`/fake --instdir `pwd`/fake --admindir=`pwd`/fake/dpkg --install *.deb
Some points to note:
--force-not-root is not enough. fakeroot is required.
ldconfig and start-stop-daemon must be on the path.
(hence PATH=/sbin:/usr/sbin:$PATH)
The log file needs to be relocated from the default /var/log/dpkg.log
The order of arguments is significant. If used --root must be before --instdir and --admindir.
The admindir is supposed to have a the installation dir as a prefix.
If the package contains any pre or post installation scripts (preinst,postinst) then --force-script-chrootless is required as these scripts are normally run via chroot() which gives operation not permitted when attempted under fakeroot.
For a quick test of trivial dependencies, you can directly install on the system using 'dpkg -i' then 'dpkg -P' and 'apt-get autoremove' to purge the package and clean the dependencies.
An other more secure but slower solution could be to use the autopkgtest package:
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
The setup I have is like this: I have two sets of libraries that are compiled for amd64 (pc) and armelx (ARM). They are both used to cross-compile some software on a build machine.
The first ones (amd64) can be updated without hassle by updating the apt-repository and using apt-get install on the build machine. The packages for ARM however, I don't want to install with apt, because it does not support installing to different directory. If I installed to default directories, the versions could not coexist. Right?
So far, the build machine was updated manually each time there was a new version of the packages, simply by extracting with dpkg -x to a dedicated "fake" footfs directory. This is where the compiler would also look when cross compiling other SW. The problem is, there is no information about these extracted packages or their versions anywhere on the system, right? It should have been in the status file.
My thought was to have these packages installed on this footfs dir with dpkg -i <package.deb> --root=<rootfs>. Would this work? I have a feeling it will not, because the deb packages have no post/pre-remove/install scripts, so it may work for a virgin install somehow, but not for upgrading? Also, what must the rootfs directory structure look like and what must it contain in order for this to work even the first time? Is there a tool to help with this?
Thanks.
Once you have a base armel Debian system, you can actually enter it and run the armel code inside it using something like QEMU. The qemu-arm-static tool (in the qemu-user-static package) can make use of the binfmt_misc capability in Linux to make it so ARM executables are directly run under the QEMU ARM system emulator. So you can run dpkg, apt-get, and so on inside the armel "rootfs" while running on amd64 hardware.
Example:
my_arm_system=/mnt/arm_system
sudo cp /usr/bin/qemu-arm-static "$my_arm_system/usr/bin/"
sudo chroot "$my_arm_system" apt-get update
sudo chroot "$my_arm_system" apt-get install $somepkg
sudo chroot "$my_arm_system" /bin/bash
As for setting up the base armel system in the first place: Debootstrap is the typical method for setting up a Debian base system, whether in a chroot or otherwise. You can use it for installing a base system of a different architecture, but it takes a few extra steps:
distro=jessie # or whatever
echo "Debootstrap phase 1"
sudo mkdir "$my_arm_system"
sudo debootstrap --arch=armel --verbose --foreign "$distro" "$my_arm_system"
sudo cp /usr/bin/qemu-arm-static "$my_arm_system"/usr/bin/
echo "Debootstrap phase 2"
sudo chroot "$my_arm_system" /debootstrap/debootstrap --second-stage
Multistrap is another tool that might be useful; it is intended for setting up Debian environments of one architecture on a host of a different architecture, or for using more complicated APT source combinations. It's not perfect, as it doesn't follow all the deb installation "rules" exactly. It takes some shortcuts/deviations in order to make its job reasonably possible.
I am trying to install ODBC driver for Debian arrording to these instructions: https://blog.afoolishmanifesto.com/posts/install-and-configure-the-ms-odbc-driver-on-debian/
However trying to run:
sqlcmd -S localhost
I get the error
libcrypto.so.10: cannot open shared object file: No such file or
directory
What could be the cause?
So far I have tried
1.
$ cd /usr/lib
$ sudo ln -s libssl.so.0.9.8 libssl.so.10
$ sudo ln -slibcrypto.so.0.9.8 libcrypto.so.10
2.
/usr/local/lib64 to the /etc/ld.so.conf.d/doubango.conf file
3.
sudo apt-get update
sudo apt-get install libssl1.0.0 libssl-dev
cd /lib/x86_64-linux-gnu
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10
4. Sudo apt-get install libssl0.9.8:i386
None of these have helped.
As I'm quite familiar with Debian and programming, here is some advice:
if you have questions about setting up your system, ask on SuperUser and/or (if your question is specific to a Un*x flavour) on Unix&Linux
when fuddling around with symlinks to shared-libraries, you should have a thorough understanding of what you are doing. these files are named for a reason - and the reason is to protect you (the user of the system) from weird crashes, because an application is using a wrong/incompatible library.
a tutorial that tells you to do so, should give proper warning and explanation about what you are to do.
So, why are these instructions in the tutorial you are following?
The application you are trying to run, has been linked against libcrypto.so.
On the developer machine (that was used to produce the application binary), libcrypto.so was a symlink to libcrypto.so.10, but this is missing on Debian: maybe because the library has been removed (and replaced by a new and incompatible version), or because Debian uses a different naming scheme as compared to the system that was used to compile the application.
If it is the former, then you cannot solve the issue by using symlinks.
You have to get the right library (or the application linked against the correct libraries).
If it is the latter, you may get away with symlinking the expected library name with the correct library files found on your system. (This is assuming that the only difference between the two systems is indeed the so-naming scheme).
So, how to do it?
first of all, you should find out, against which libraries your application was really linked, and which of these libraries are missing.
$ ldd /path/to/my/app | grep -i "not found"
libfoo.so.10 => not found
then find out, whether you have a (hopefully compatible) library on your system. A good place to start is /usr/lib/. but not-so-recently, Debian has started moving the libraries to /usr/lib/<host-triplet>, with <host-triplet> describing a target architecture. You can find out the default value if your application was indeed built for the architecture you are running (e.g. for linux-amd64) you can get the string by running something like:
$ gcc -print-multiarch
Imagine you discover that you have /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0.
if you have good reason to believe that this can act as a replacement for libfoo.so.10, you can go make the found library available to your application by means of a symlink, e.g.
# cd /usr/local/lib/
# ln -s /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0 libfoo.so.10
Finally, you might need to refresh the cache of the dynamic linker so it starts using the new library, by running ldconfig as root/superuser.