Invoking prusa-slicer from $PATH environment variable crashes

[hzeller]

Version

PrusaSlicer-2.3.0-beta3+linux-x64-202012121815

Operating system type + version

This is on Linux.

Behavior

Prusa slicer starts up when invoked directly with an absolute or relative path

tar xjf ~/Downloads/PrusaSlicer-2.3.0-beta3+linux-x64-202012121815.tar.bz2

# invoking the binary by providing the path to it starts up the application fine
PrusaSlicer-2.3.0-beta3+linux-x64-202012121815/bin/prusa-slicer

.. However, when invoked from the environment $PATH variable, it crashes

# Crashes
export PATH=`pwd`/PrusaSlicer-2.3.0-beta3+linux-x64-202012121815/bin/:$PATH

# Now invoking it just with prusa-slicer, the shell finds it in $PATH, but then binary crashes
prusa-slicer 
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::canonical: No such file or directory: "/tmp/prusa-slicer"
Aborted

Note, how it attempts to assemble the path from the current directory + argv[0] and arrives at /tmp/prusa-slicer. Which is of course wrong.

[lukasmatena]

Thanks, I managed to reproduce it on Ubuntu 16.04. Related to #4973.

My attempt to fix it was

--- a/src/PrusaSlicer.cpp
+++ b/src/PrusaSlicer.cpp
@@ -28,6 +28,7 @@
 #include <boost/nowide/cenv.hpp>
 #include <boost/nowide/iostream.hpp>
 #include <boost/nowide/integration/filesystem.hpp>
+#include <boost/dll/runtime_symbol_info.hpp>
 
 #include "unix/fhs.hpp"  // Generated by CMake from ../platform/unix/fhs.hpp.in
 
@@ -598,7 +599,7 @@ bool CLI::setup(int argc, char **argv)
         }
     }
 
-    boost::filesystem::path path_to_binary = boost::filesystem::system_complete(argv[0]);
+    boost::filesystem::path path_to_binary = boost::dll::program_location();
 
     // Path from the Slic3r binary to its resources.
 #ifdef __APPLE__

And it works on my system. I peeked into boost source and it apparently does the same as you propose in #5543. At least on Linux (there is some OS-specific gymnastics for the other systems as well).

Anyone has some experience about how reliable this would be?

[hzeller]

I confirm that this also works on my system. Given that this uses a boost-provided method that is dedicated for this task, I think this is the better solution @lukasmatena than my Linux-specific hack in #5543 .

[bubnikv]

Fixed with 293f85b