Multimc5: GetPrerequisites.cmake doesn't detect the main binary as executable, leading to install errors

[44trent3]

When I try to do make install I get this error.

[peterix]

What distro is that? Which version of CMake?

[peterix]

As a workaround, you could just disable the bundling of dependencies by commenting out this line:
https://github.com/MultiMC/MultiMC5/blob/develop/application/CMakeLists.txt#L476

[RandomVillain]

Not the original poster, but having the same problem on Debian; following the build instructions with freshly cloned source, but install phase fails with:

$ cat build.sh
git clone --recursive https://github.com/MultiMC/MultiMC5.git src
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=../files ../src
make -j8 install
$ ./build.sh
[...]
Install the project...
-- Install configuration: ""
-- Installing: /tmp/multimc/files/bin/MultiMC
-- Set runtime path of "/tmp/multimc/files/bin/MultiMC" to ""
-- Installing: /tmp/multimc/files/./MultiMC
-- Installing: /tmp/multimc/files/bin/jars/JavaCheck.jar
-- Installing: /tmp/multimc/files/bin/jars/NewLaunch.jar
-- Installing: /tmp/multimc/files/plugins/imageformats
-- Installing: /tmp/multimc/files/plugins/imageformats/libqwbmp.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqgif.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqicns.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqwebp.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqico.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqsvg.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqjpeg.so
-- Installing: /tmp/multimc/files/plugins/imageformats/libqdds.so
-- Installing: /tmp/multimc/files/plugins/iconengines
-- Installing: /tmp/multimc/files/plugins/iconengines/libqsvgicon.so
-- Installing: /tmp/multimc/files/plugins/platforms
-- Installing: /tmp/multimc/files/plugins/platforms/libqeglfs.so
-- Installing: /tmp/multimc/files/plugins/platforms/libqxcb.so
-- fixup_bundle
--   app='/tmp/multimc/files/bin/MultiMC'
--   libs='/tmp/multimc/files/plugins/iconengines/libqsvgicon.so;/tmp/multimc/files/plugins/imageformats/libqdds.so;/tmp/multimc/files/plugins/imageformats/libqgif.so;/tmp/multimc/files/plugins/imageformats/libqicns.so;/tmp/multimc/files/plugins/imageformats/libqico.so;/tmp/multimc/files/plugins/imageformats/libqjpeg.so;/tmp/multimc/files/plugins/imageformats/libqsvg.so;/tmp/multimc/files/plugins/imageformats/libqwbmp.so;/tmp/multimc/files/plugins/imageformats/libqwebp.so;/tmp/multimc/files/plugins/platforms/libqeglfs.so;/tmp/multimc/files/plugins/platforms/libqxcb.so'
--   dirs='/usr/lib/x86_64-linux-gnu;/usr/lib/x86_64-linux-gnu/qt5/libexec;/tmp/multimc/build;/tmp/multimc/build'
-- warning: *NOT* handled - not .app dir, not executable file...
CMake Error at /tmp/multimc/src/cmake/BundleUtilities.cmake:668 (message):
  error: fixup_bundle: not a valid bundle
Call Stack (most recent call first):
  application/install_prereqs.cmake:24 (fixup_bundle)
  application/cmake_install.cmake:86 (include)
  cmake_install.cmake:50 (include)

-- fixup_bundle: done
Makefile:83: recipe for target 'install' failed
make: *** [install] Error 1

(very similar to previous log, but pasted here for benefit of future searches)

$  cmake --version
cmake version 3.7.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

The workaround link now points at a blank line, but old versions (and the stack trace) suggests the nearby "install(" line that references install_prereqs.cmake, and commenting out this line allows make to complete without error. The resulting install dies looking for libMultiMC_gui.so (and a few others), which were simply left behind in the build directory (assuming this was supposed to be handled by that commented-out line), but manually copying them to $install_dir/bin lets it start up.

[Yepoleb]

Permalink of the line to remove: https://github.com/MultiMC/MultiMC5/blob/d70c783de8ae842ea175ee92902c31c088c2ddda/application/CMakeLists.txt#L527

Is bundling the dependencies even necessary when building from source? It's definitely a good idea for generic builds, but when I compile against my own libraries, it's seems like a waste of space.

[peterix]

You can now use a different installation layout:
https://github.com/MultiMC/MultiMC5/blob/d70c783de8ae842ea175ee92902c31c088c2ddda/application/CMakeLists.txt#L307

• lin-bundle is the portable application layout with all the dependencies included
• lin-nodeps is the portable application layout without the extra dependencies - it doesn't use bundle utilities and shouldn't trigger those CMake errors.
• lin-system is the layout used for linux system packaging (see https://aur.archlinux.org/packages/multimc-git and https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=multimc-git#n32 for an example of use). Again, no bundle utilities.

[Yepoleb]

The problem with bundled dependencies seems to be that is_file_executable doesn't detect the application as executable, because of a change in the output of the file command. This has already been patched in at least the latest version of GetPrerequisites.cmake. I suggest to update the bundled modules or use the system installed versions.

Thanks for the different installation layouts!

[peterix]

I couldn't replicate the issue on Arch linux, thanks for the hint :)

[Yepoleb]

Arch doesn't build position independent executables by default, while Debian does, so that's probably the reason why you couldn't reproduce the issue.

[samis]

Just reproduced this with Gentoo, which has very recently decided to switch to PIE-by-default (17.0 profiles)

[draeath]

This is reproducible on the 'stable' branch, with Debian Stretch, as-of this time.

[draeath]

Can we get Yepoleb's suggestion implemented? The included modules are quite old, this fix is over 2 years old, cmake-side.

I've confirmed that it works.

[Yepoleb]

I'm wondering why the module was even included in the first place. The commit description of 27732d66b4781ef480e9b3f8a10601f707b9d555 leaves me clueless.

[peterix]

Please do not use the bundled dependencies layout when building it yourself for your local machine.

There is a MultiMC_LAYOUT variable you can set to other, much more appropriate values for that purpose:

• lin-nodeps is the portable layout without running bundle utilities and without including system dependencies.
• lin-system is a layout suitable for linux packaging.

See https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=multimc-git for an example of how to set this, and how the lin-system layout can be used.

[Yepoleb]

When I experienced this bug, I didn't choose to bundle the dependencies, it was simply the default. Judging by the comments on this issue it still is. But while changing the default is certainly a nice improvement on its own, I think resolving this issue by updating the module can't really hurt either.

[peterix]

So really, the default should probably change to lin-system, the BUILD.md needs updating and I should include a default .desktop and icon file.

[peterix]

The build system now defaults to lin-nodeps on linux, so at least this shouldn't be an immediate problem to people building it for the first time.

[draeath]

Thanks!!

[peterix]

I absolutely can't use the bundle utilities included with current cmake. They add symlinks to everything and it would completely break the updater. It's really not set up to handle symlinks - and never was. Even if I implemented that now, I'd break updates for everyone.

[peterix]

This should be now fixed, along with other related issues reported on discord.
Specifically:

• Libraries are now installed with correct RPATH and file permissions.
• The build system treats CMAKE_INSTALL_PREFIX and DESTDIR correctly now and installation with the lin-system layout should behave as most people expect.
• The silly bundle utilities bug related to the file utility has been fixed. Thanks @Yepoleb and @draeath for bringing it up. I'm not running into it in my build environments and the default has been changed to lin-nodeps, but if anyone wants to build the full fat bundles on something weird... they now can.

Anyway, I'll be on the lookout for better build systems...