** Description changed: - Hello, + [Impact] - With Ubuntu 16.04, When I try to open Muse sequencer, here is what - happens : + Since Ubuntu 15.10, muse does not start and gives the following error: - ~$ muse + $ muse muse: error while loading shared libraries: libmuse_core.so: cannot open shared object file: No such file or directory - I searched. The file is nowhere to be found in my system. + The fix for this should be backported to Xenial since muse is currently + useless "as is". - ProblemType: Bug - DistroRelease: Ubuntu 16.04 - Package: muse 2.1.2-1build1 - ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10 - Uname: Linux 4.4.0-24-generic x86_64 - NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia - ApportVersion: 2.20.1-0ubuntu2.1 - Architecture: amd64 - CurrentDesktop: Unity - Date: Mon Jun 27 12:01:03 2016 - InstallationDate: Installed on 2016-02-02 (146 days ago) - InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) - SourcePackage: muse - UpgradeStatus: Upgraded to xenial on 2016-04-22 (66 days ago) + [Technical Details] + + Force muse modules to be installed under /usr/lib/muse + + Ubuntu CMake contains the script 'MultiArchCross.cmake' which is invoked for all + Make packages and sets CMAKE_INSTALL_LIBDIR to include the multiarch path + without the install prefix (ie something like "lib/x86_64-linux-gnu"). This + variable is not defined when building on Debian. + + Muse constructs a LIB_INSTALL_DIR variable (when it's not defined) using + CMAKE_INSTALL_LIBDIR or an alternate fallback. Unfortunately later on in the + script when handling the RPATH settings, Muse assumes that LIB_INSTALL_DIR is an + absolute path. This is true on Debian, but not on Ubuntu. This causes a bogus + RPATH to be inserted into the main Muse executable which prevents Muse from + finding any of it's modules and immediately crashes on startup. + + The simple fix is to force LIB_INSTALL_DIR=/usr/lib. Although an Ubuntu specific + problem, it does no harm to do this on Debian as well. + + [Test Case] + + From within a terminal window, run "muse". The following error is printed: + muse: error while loading shared libraries: libmuse_core.so: cannot open shared object file: No such file or directory + + When working normally, the muse arranger window should appear. If an error + appears about Jack not running, you can ignore it. + + [Regression Potential] + + Muse is a totally independant application with no reverse dependencies + in the archive. Therefore it is unlikely there will be any regressions + in other packages. + + Since Muse is completely non-functional in Xenial, it's difficult for it + to regress any furthur. :) + + [Other Info] + + A workaround for this bug is to set the linker path manually when + running muse. For example: + + LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/muse/modules muse
** Description changed: [Impact] Since Ubuntu 15.10, muse does not start and gives the following error: $ muse muse: error while loading shared libraries: libmuse_core.so: cannot open shared object file: No such file or directory The fix for this should be backported to Xenial since muse is currently useless "as is". [Technical Details] Force muse modules to be installed under /usr/lib/muse - - Ubuntu CMake contains the script 'MultiArchCross.cmake' which is invoked for all - Make packages and sets CMAKE_INSTALL_LIBDIR to include the multiarch path + + Ubuntu CMake contains the script 'MultiArchCross.cmake' which is invoked for all Make packages and sets CMAKE_INSTALL_LIBDIR to include the multiarch path without the install prefix (ie something like "lib/x86_64-linux-gnu"). This variable is not defined when building on Debian. - + Muse constructs a LIB_INSTALL_DIR variable (when it's not defined) using CMAKE_INSTALL_LIBDIR or an alternate fallback. Unfortunately later on in the - script when handling the RPATH settings, Muse assumes that LIB_INSTALL_DIR is an - absolute path. This is true on Debian, but not on Ubuntu. This causes a bogus - RPATH to be inserted into the main Muse executable which prevents Muse from - finding any of it's modules and immediately crashes on startup. - - The simple fix is to force LIB_INSTALL_DIR=/usr/lib. Although an Ubuntu specific - problem, it does no harm to do this on Debian as well. + script when handling the RPATH settings, Muse assumes that LIB_INSTALL_DIR is an absolute path. This is true on Debian, but not on Ubuntu. This causes a bogus RPATH to be inserted into the main Muse executable which prevents Muse from finding any of it's modules and immediately crashes on startup. + + The simple fix is to force LIB_INSTALL_DIR=/usr/lib. Although an Ubuntu + specific problem, it does no harm to do this on Debian as well. [Test Case] From within a terminal window, run "muse". The following error is printed: muse: error while loading shared libraries: libmuse_core.so: cannot open shared object file: No such file or directory When working normally, the muse arranger window should appear. If an error appears about Jack not running, you can ignore it. [Regression Potential] - Muse is a totally independant application with no reverse dependencies + Muse is a totally independent application with no reverse dependencies in the archive. Therefore it is unlikely there will be any regressions in other packages. Since Muse is completely non-functional in Xenial, it's difficult for it - to regress any furthur. :) + to regress any further. :) [Other Info] A workaround for this bug is to set the linker path manually when running muse. For example: LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/muse/modules muse -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1596486 Title: libmuse_core.so: cannot open shared object file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/muse/+bug/1596486/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
