"libhydrogen-core-1.0.0.so" missing

[ghost]

Hydrogen version * : Latest git build Operating system + version : Manjaro 64-bit. Kernel 4.14.85 Audio driver + version : JACK2 D-BUS, 1.9.12

---

Hydrogen doesn't start up for me. When running from the terminal, I get the message "hydrogen: error while loading shared libraries: libhydrogen-core-1.0.0.so: cannot open shared object file: No such file or directory". That being said, the aforementioned file is in /usr/local/lib. After reading #255 , I also tried running ldconfig after make install, though this didn't fix the problem. I would appreciate any help with this, thanks.

Edit: I found that I can run hydrogen, but only from the build directory. I can't run hydrogen from the terminal though.

[trebmuh]

Hi @FrictionCow , I've just tried here from a fresh build (https://github.com/hydrogen-music/hydrogen/commit/bbeaed1a5d46414360cbce74e81fbcc0a05e26f6) and I can't reproduce (Debian Stretch / LibraZiK-2 system).

Can you please try to retry from current git head master and tell us if that's is still the same? In such a case, give us the command lines you're using to build H2.

[mauser]

Closed, due to missing feedback. Just mention it if the problem still persists.

[Digital-Larry]

I did this build today and had the same issue. It turns out that the /usr/local/lib/libhydrogen-core-1.0.0.so file is not set as executable. I changed that and it works now.

I'm using Ubuntu Studio 19. Linux ub-studio 5.0.0-27-lowlatency #28-Ubuntu SMP PREEMPT Tue Aug 20 20:33:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

This is how I built Hydrogen:

cd Downloads/
git clone git://github.com/hydrogen-music/hydrogen.git
cd hydrogen/
sudo apt-get install qtbase5-dev qtbase5-dev-tools            qttools5-dev qttools5-dev-tools libqt5xmlpatterns5-dev  libarchive-dev libsndfile1-dev libasound2-dev liblo-dev libpulse-dev libcppunit-dev liblrdf-dev                 liblash-compat-dev librubberband-dev
mkdir build && cd build
cmake ..
make && sudo make install

[fredvs]

Hello.

Same problem here on Debian 10.1. To fix it, I did create a symlink /usr/lib/libhydrogen-core-1.0.0.so to /usr/local/lib/libhydrogen-core-1.0.0.so

Now all seems OK and I am excited o try the new version.

Thanks.

Fre;D

[jackson-elfers]

@fredvs Just encountered the same issue. It appears it's ending up in the wrong folder but sym linking did the trick thanks. Running Ubuntu 19.04 btw.

[Daxx]

Same as @Digital-Larry /usr/local/lib/libhydrogen-core-1.0.0.so file not executable

mkdir build && cd build cmake .. make && sudo make install

Thanks. Ubuntu 14.04

[grammoboy2]

confirmed

(temporal) solution seems to be: sudo ln -s /usr/local/lib/libhydrogen-core-1.0.0.so /usr/lib/libhydrogen-core-1.0.0.so

[trebmuh]

@mauser ping.

[elpescado]

This is perplexing. The issue is, as I understand

1. cmake by default installs Hydrogen in /usr/local (this can be overridden by CMAKE_INSTALL_PREFIX), so that hydrogen executable goes to /usr/local/bin and libhydrogen-core-1.0.0.so goes to /usr/local/lib. Simple.
2. /usr/local/bin is in $PATH in most (all?) Linux distributions, so executables can be found, whereas
3. /usr/local/lib is not in $LD_LIBRARY_PATH in most (all?) distros, so libraries needed by hydrogen cannot be found. Boom!

Now, who's to blame?

1. cmake, because it puts everything in wrong place?
2. user, because CMAKE_INSTALL_PREFIX was not set?
3. Linux, because of lack of symmetry between $PATH and $LD_LIBRARY_PATH?
4. hydrogen, because we're using make wrong?

I don't know. It's perplexing, as I said before.

Maybe we should look at how other projects deal with similar situation.

[elpescado]

OK, I've been thinking about this for a little, an I think I have a solution. But let's go back to that later.

At first I was leaning towards the idea that it's user error by not specifying CMAKE_INSTALL_PREFIX (akin to --prefix in ./configure). Installing Hydrogen to /usr should work. But. First, /usr/local/lib is the default, and users should expect that defaults work correctly. Second, /usr is reserved for system software and installing 3rd party there is wrong and asking for trouble, and once package manager starts installing/upgrading/removing system packages things are likely to get borked. So now I think that blame is somehow shared between Linux and cmake for having insane defaults (I think that libtool in autotools does handle this case and if I say something positive about autotools, it means a lot), but it's our bug tracker that gets all those bug reports.

What can we do? I think we could rename Hydrogen binary to hydrogen.bin, hydrogen.exe, hydrogen.gui or something like this (on Linux, so MacOS and Windows binaries remain hydrogen and hydrogen.exe respectively). Then we could create simple launcher script /usr/local/bin/hydrogen that sets up correct environment variables and runs main binary, something along the lines:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
exec /usr/local/bin/hydrogen.bin

Where /usr/local/bin is substituted by cmake to whatever CMAKE_INSTALL_PREFIX is set too. That way Hydrogen could be run by typing hydrogen, and could find its libraries no matter where they are installed and whether or not they're in LD_LIBRARY_PATH. Maybe configure_file directive could help us do this.

Cheers!

[elpescado]

Alternatively, we might add -Wl,-rpath=/usr/local/lib flag to gcc.

[mauser]

Hi!

the last option looks less intrusive to me, but i'm no expert. But if i understand the issue correctly, it would be sth. like -Wl,-rpath=${CMAKE_INSTALL_PREFIX}/lib, not a fixed /usr/local/lib. Correct?

@jeremyz : You seem to have a better understanding of cmake :) Do you have an opinion on this issue?

[jeremyz]

Hi all,

I think that's a bit silly, not a project I know does something about it.

On most (all) distros, /usr/local/bin is no more in PATH and /usr/local/lib is not handled by ldconfig. But all build systems default to /usr/local as install path, even one of the latest : meson. And that's correct, you should use your package manager, if not, do not mix your user installed files with the packager managed files, thus install into /usr/local (myself into /usr/local/h2).

about the LD_LIBRARY_PATH script, I don't think that distro packager would love to see an extra and useless shell script when they package h2, I guess they would have extra work to remove it ... no good.

Personaly, I would set some notes in INSTALL.md and maybe a warning in cmake output when prefix is /usr/local/*, no more. Teaching users is good ;)

I can do that if you agree.

[jeremyz]

feel free to improve my explanations and English.

[trebmuh]

LGTM @jeremyz

[wolftune]

@jeremyz the instructions are not well-written enough to help me learn:

If Hydrogen doesn't start, it might be because it's shared library is not found.
You can verify this with the above command :
```ldd CMAKE_INSTALL_PREFIX/bin/hydrogen | grep 'not found'```

To fix this, you can use LD_PRELOAD or LD_LIBRARY_PATH environment variables,
or configure ldconfig (man ldconfig).

Another option is to set -DCMAKE_INSTALL_PREFIX=/usr, recompile and reinstall Hydrogen.
But be aware that you will certainly overwrite Hydrogen files that you might have
installed with your distribution's package manager.

First, it says "above command" but the command is below. That's confusing.

"you can use LD_PRELOAD or LD_LIBRARY_PATH environment variables" doesn't explain how someone uses those variables. For people who aren't developers, it needs to explain exactly how to "use" them.

"Another option is to set -DCMAKE_INSTALL_PREFIX=/usr" Okay, but which of the commands during the build process is the one that gets this option added to it?

Incidentally, the symlink is what I did to get this to work. sudo ln -s /usr/local/lib/libhydrogen-core-1.0.0.so /usr/lib/libhydrogen-core-1.0.0.so

[jeremyz]

Hello,

you're right, above is not below, I'll fix that.

about the rest, I don't know ... an INSTALL file is not the place to learn about these topics. Where did you get the symlink trick, do you know why it works, do you know what could happen if after that you install h2 from your distro, should we explain exactly all of that ? should we also explain exactly the usage of the PATH var mentioned a few lines above ?

maybe we should set an troubleshooting wiki page and relieve a bit that over bloated INSTALL file. what do you think ?

(btw -DCMAKE_INSTALL_PREFIX is explained a few lines above, int the Additional Build Features and Uninstall section).

I can tell you what I do, I have a cmake_opts file :

#! /bin/bash

QTDIR=${QTDIR:-/usr/lib/qt}
VERBOSE=${VERBOSE:-0}
CMAKE_OPTIONS="
    -DCMAKE_COLOR_MAKEFILE=1 \
    -DWANT_DEBUG=1 \
    -DWANT_JACK=1 \
    -DWANT_ALSA=1 \
    -DWANT_LIBARCHIVE=1 \
    -DWANT_RUBBERBAND=1 \
    -DWANT_OSS=1 \
    -DWANT_PORTAUDIO=1 \
    -DWANT_PORTMIDI=1 \
    -DWANT_LASH=1 \
    -DWANT_LRDF=1 \
    -DWANT_COREAUDIO=1 \
    -DWANT_COREMIDI=1 \
    -DQt5_DIR=/opt/qt5/lib/cmake
    -DCMAKE_INSTALL_PREFIX=/opt/hydrogen
    -DCMAKE_PREFIX_PATH=/opt/qt5/lib/cmake
"
MAKE_OPTS="-j 3"
H2FLAGS="-V0xf"
BUILD_DIR=./build

I use ./build.sh z to build and run from tree.

If I realy want to install h2, I have a user writeable /opt/hydrogen sudo mkdir /opt/hydrogen && sudo chown _user_ /opt/hydrogen. To install I do rm -fr /opt/hydrogen/* && cd build/ && make install And to run : LD_PRELOAD=/opt/hydrogen/lib/libhydrogen-core-1.0.0.so /opt/hydrogen/bin/hydrogen (that's what build.sh z does)

[wolftune]

@jeremyz

I agree that explaining concepts here is wrong, I mentioned that because you wrote "Teaching users is good ;)"

Where did you get the symlink trick

From earlier replies in this here issue

(btw -DCMAKE_INSTALL_PREFIX is explained a few lines above, int the Additional Build Features and Uninstall section).

Perhaps just the solution there is to add: "as described above in the Additional Build Features and Uninstall section"

I don't really understand the issues enough to discuss the correct solutions here, I just am noting that the INSTALL file right now is not clear in its instructions. The suggestions I'm making now seem adequate as a simple next step. I don't know what would make things even clearer and more straightfoward or how the symlink issue applies.

[elpescado]

Here's nice discussion of this topic: https://stackoverflow.com/questions/7099712/whats-the-accepted-method-for-deploying-a-linux-application-that-relies-on-shar

[cme]

Hi guys. I hadn't seen this before, there's a factor that hasn't been brought up in the discussion, and which I think simplifies things in terms of delineation of responsibility.

ld uses different mechanisms for finding libraries in different locations. In particular, "system" locations like /lib, /usr/lib, and /usr/local/lib on some distros, are found using ld.so.config and ld.so.cache. Since this uses a cache to make library lookup fast, ldconfig has to be re-run before any new library in these locations is noticed. Usually package managers do this after installing libraries.

Some library build systems seem to have explicit sudo ldconfig in their install target, but this doesn't seem appropriate to me, as

1. it's only necessary if the install prefix is a system location, and
2. install scripts have no way of knowing that unless they parse /etc/ld.so.config

I've seen other libraries with install targets that just emit a message saying "you may need to do other stuff like run ldconfig", and I think that's probably the best compromise.

Maybe Hydrogen should do that, and document accordingly?

[theGreatWhiteShark]

@cme If running sudo ldconfig fixes the situation for those some distros, putting this command instead of (or at least in addition to) the more technical description in the INSTALL.md would be a good idea.

I would also replace the phrase

If Hydrogen doesn't start, it might be because it's shared library is not found.

in the INSTALL.md with the actual error message "libhydrogen-core-X.X.X.so" missing.

I've seen other libraries with install targets that just emit a message saying "you may need to do other stuff like run ldconfig", and I think that's probably the best compromise.

Maybe Hydrogen should do that, and document accordingly?

+1