Closed ghost closed 4 years ago
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.
Closed, due to missing feedback. Just mention it if the problem still persists.
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
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
@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.
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
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
@mauser ping.
This is perplexing. The issue is, as I understand
/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./usr/local/bin
is in $PATH
in most (all?) Linux distributions, so executables can be found, whereas/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?
CMAKE_INSTALL_PREFIX
was not set?$PATH
and $LD_LIBRARY_PATH
?I don't know. It's perplexing, as I said before.
Maybe we should look at how other projects deal with similar situation.
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!
Alternatively, we might add -Wl,-rpath=/usr/local/lib
flag to gcc.
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?
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.
feel free to improve my explanations and English.
LGTM @jeremyz
@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
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)
@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.
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
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
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?
@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
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.