search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.41k stars 1.88k forks source link

Unable to build slic3r pe on Mac OS because of Slic3r/XS.pm missing #1421

Closed PatrikTheDev closed 5 years ago

PatrikTheDev commented 5 years ago

Hi, I am unable to compile Slic3r because of Slic3r/XS.pm missing and cmake failing because of its inability to find TBB (I ran brew install TBB just to be sure and it still does not work), what am I doing wrong? I am following your guide in the docs. BTW I am unable to compile the regular version of Slic3r as well

PatrikTheDev commented 5 years ago

BTW if there would be someone that would help me over team viewer I would realllllyyyyy appreciate it

PatrikTheDev commented 5 years ago

I like how the OG slic3r has the automated builds, would it be hard to implement?

bubnikv commented 5 years ago

We implemented automated builds on our build server. It was not easy to implement.

PatrikTheDev commented 5 years ago

Thaaaaankk you a lot!!

PatrikTheDev commented 5 years ago

BTW where can I download the builds? I dont see anything about it in the readme

vojtechkral commented 5 years ago

@Patrik-svobodik Hi. There's basically 3 steps to build on Mac: 1. Get the appropriate SDK, 2. Build dependencies, 3. Build Slic3rPE.

  1. We currently only support building Slic3rPE against Mac OS X SDK 10.9. You can download it online, for example here.
  2. To build the dependencies, go to the deps subdirectory in Slic3rPE sources. Make a new directory named deps-build or something similar, cd into it and call cmake: cmake .. -DDEPS_OSX_SYSROOT=<path to SDK 10.9> and then make. This will create a dependencies bundle inside the deps-build/destdir directory.
  3. Go to the top-level Slic3rPE directory and create a subdirectory called build or similar, cd into it and prepare using CMake:

cmake .. "-DCMAKE_PREFIX_PATH=${PWD}/../deps/deps-build/destdir/usr/local" -DCMAKE_OSX_SYSROOT=<path to SDK 10.9>

And then call make (or make -jN where N is the number of your CPU cores to speed up).

If all goes well, Slic3rPE should be built, the main executable should be at build/src/slic3r-gui.

Alternatively, if you prefer XCode, you can add -GXCode to the cmake call in step 3., then instead of calling make you open build/Slic3r.xcodeproj and proceed building using XCode.

ctilley83 commented 5 years ago

@vojtechkral Your guide helped me understand how this works. I’m able to follow steps 1 and 2 successfully, but the last cmake command in step 3 seems to be ignoring the dependency path argument and is still trying to use a global tbb package I have installed. Is there a flag to specify the location for that particular library in the /deps/deps-build/destdir we generated?

bubnikv commented 5 years ago

Try export TBB_INSTALL_DIR=...

bubnikv commented 5 years ago

see Slic3r/cmake/modules/FindTBB.cmake

PatrikTheDev commented 5 years ago

Hi, I am struggling on the step 3 too, it uses global make modules for some reason, and fails on: CMake Error at /usr/local/Cellar/cmake/3.12.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find TBB (missing: TBB_LIBRARIES) (found version "2019.0") Call Stack (most recent call first): /usr/local/Cellar/cmake/3.12.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) cmake/modules/FindTBB.cmake:273 (find_package_handle_standard_args) CMakeLists.txt:191 (find_package)

What should I do?

PatrikTheDev commented 5 years ago

@vojtechkral BTW will you update the build instructions in. the docs folder?

ctilley83 commented 5 years ago

@vojtechkral Specifically build instructions for mac running mojave would be nice.

vojtechkral commented 5 years ago

@Patrik-svobodik @ctilley83 Yes, I'll be updating the docs folder ... once I get around to do that :)

vojtechkral commented 5 years ago

@Patrik-svobodik @ctilley83 Regarding TBB, it's possible there is a problem, although it didn't manifest on our Mac. I'll look into it...

PatrikTheDev commented 5 years ago

@bubnikv and regarding the automated builds, where can I download them?

ctilley83 commented 5 years ago

@vojtechkral It might be specific to machines running Mojave. I tried searching to see if there was a path variable set somewhere and didn't find one, but it seems find.tbb is including the global FindPackageHandleStandardArgs.cmake, instead of the one in the local make/modules directory.

vojtechkral commented 5 years ago

@ctilley83 We have Mojave as well. Do you by any chance have TBB in /opt/intel/tbb?

ctilley83 commented 5 years ago

@vojtechkral I do, but had the error before I installed TBB directly from Intel. Part of my troubleshooting for the TBB error was to install it. I'll uninstall it and see if that helps

PatrikTheDev commented 5 years ago

@vojtechkral I have it in /usr/local/Cellar/tbb/2019_U3, is it a problem? I installed it using Homebrew, idk how to force it to install in /opt/intel/tbb

vojtechkral commented 5 years ago

@ctilley83 @Patrik-svobodik I have installed tbb on our dev Mojave machine using brew as well. I will test it and try to figure out whatever is going on in there. Today we had a similar problem on one Linux box and I think it's related. It may take me some time to figure this out (what with being occupied by other issues as well).

Out of curiosity @ctilley83 how did you install tbb?

ctilley83 commented 5 years ago

@vojtechkral originally installed through homebrew. I then tried installing directly from intel. I think it's expecting a different version of tbb than what it's finding. I just tried on a brand new laptop and the error is the same.

Could NOT find TBB (missing: TBB_LIBRARIES) (found version "2019.0")

PatrikTheDev commented 5 years ago

@vojtechkral for some reason the second step started failing with the same error for me: CMake Error at /usr/local/Cellar/cmake/3.13.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find TBB (missing: TBB_LIBRARIES) (found version "2019.0") Call Stack (most recent call first): /usr/local/Cellar/cmake/3.13.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) cmake/modules/FindTBB.cmake:273 (find_package_handle_standard_args) CMakeLists.txt:191 (find_package)

vojtechkral commented 5 years ago

I think it's expecting a different version of tbb than what it's finding.

Actually I believe the meaning of the error is that it found the headers (from which it gleans the version number I think) but then doesn't find the library objects for some reason. I'm still looking into it.

vojtechkral commented 5 years ago

I'm having a hard time reproducing the problem. @ctilley83 Would you please explain to me how exactly you installed the non-homebrew TBB variant? Also the full CMake output up until the error message would be helpful and a directory listing of deps/deps-build/destdir/usr/local/lib too. Thanks!

Fabbi commented 5 years ago

I had the same problem and the TBB version from homebrew. After some digging I found that the Slic3r/cmake/modules/FindTBB.cmake searches for _static libraries but my installation only contained the normal ones. this fixed it for me. 

diff --git a/cmake/modules/FindTBB.cmake b/cmake/modules/FindTBB.cmake
index e5115ab44..bd5b8dc94 100644
--- a/cmake/modules/FindTBB.cmake
+++ b/cmake/modules/FindTBB.cmake
@@ -216,7 +216,7 @@ if(NOT TBB_FOUND)
     if(";${TBB_FIND_COMPONENTS};tbb;" MATCHES ";${_comp};")

       # Search for the libraries
-      find_library(TBB_${_comp}_LIBRARY_RELEASE ${_comp}${TBB_STATIC_SUFFIX}
+      find_library(TBB_${_comp}_LIBRARY_RELEASE ${_comp} ${_comp}${TBB_STATIC_SUFFIX}
           HINTS ${TBB_LIBRARY} ${TBB_SEARCH_DIR}
           PATHS ${TBB_DEFAULT_SEARCH_DIR} ENV LIBRARY_PATH
           PATH_SUFFIXES ${TBB_LIB_PATH_SUFFIX})

but then I got loads of Slic3r/src/glew/src/glew.c:2777:1: error: unknown type name 'PFNGLCLEARDEPTHFOESPROC'; did you mean 'PFNGLCLEARDEPTHFPROC'?. It seems that Slic3r/src/glew/src/glew.c uses my system glew.h which doesn't have the OES typedefs.

Fabbi commented 5 years ago

but now I'm getting

Undefined symbols for architecture x86_64:
"orgQhull::Qhull::runQhull(char const*, int, int, float const*, char const*)", referenced from:
    Slic3r::TriangleMesh::convex_hull_3d() const in liblibslic3r.a(TriangleMesh.cpp.o)
"_fchmodat", referenced from:
    boost::filesystem::detail::permissions(boost::filesystem::path const&, boost::filesystem::perms, boost::system::error_code*) in libboost_filesystem-mt.a(operations.o)
vojtechkral commented 5 years ago

@Fabbi Thanks for the investigation and the FindTBB patch! I'll have a look.

vojtechkral commented 5 years ago

@Fabbi if you're using dynamic TBB build, I take you're not using my deps cmake script? I'm afraid the TBB patch doesn't solve the problem when using deps.

Fabbi commented 5 years ago

I did use your deps cmake script but I had TBB installed before via brew and it seems that this one has precedence over the other. I think that is the issue others here are having, too. Cmake finds their TBB but as it looks for the _static one it doesn't populate the TBB_LIBRARIES var, thus the error.

edit: The "patch" is only a hacky workaround for those who have a system TBB that is found but not used, since it does seem to ignore the local one then. I'll keep investigating

Fabbi commented 5 years ago

same with the glew.h. It tries to compile the local glew.c and finds the system glew.h which doesn't define some macros.

vojtechkral commented 5 years ago

I did use your deps cmake script but I had TBB installed before via brew and it seems that this one has precedence over the other. I think that is the issue others here are having, too. Cmake finds their TBB but as it looks for the _static one it doesn't populate the TBB_LIBRARIES var, thus the error.

Ok. Would you please try again using the deps and share with me your log of cmake output as well as the contents of CMakeCache.txt? (Unless they contain private information, but that shouldn't be the case I think. Feel free to redact whatever you would not want shared.)

Fabbi commented 5 years ago

I found the issue. You can't use relative paths for CMAKE_PREFIX_PATH as they will be relative to the CMakeLists.txt. Either use the absolute path in your step 3 or do something like this (little bit hacky...):

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 781dbd01a..faab374d7 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -42,6 +42,15 @@ if (MSVC)
     add_compile_options(-bigobj -Zm316)
 endif ()

+set (REAL_CMAKE_PREFIX_PATH "")
+foreach(_PREFIX_PATH ${CMAKE_PREFIX_PATH})
+       if (NOT IS_ABSOLUTE _PREFIX_PATH)
+               set (_PREFIX_PATH "${CMAKE_CURRENT_BINARY_DIR}/${_PREFIX_PATH}")
+       endif()
+       get_filename_component(_REAL_PATH ${_PREFIX_PATH} REALPATH)
+       list(APPEND REAL_CMAKE_PREFIX_PATH ${_REAL_PATH})
+endforeach(_PREFIX_PATH)
+set (CMAKE_PREFIX_PATH ${REAL_CMAKE_PREFIX_PATH})

 # Display and check CMAKE_PREFIX_PATH
 message(STATUS "SLIC3R_STATIC: ${SLIC3R_STATIC}")

After this I was able to build it without any problems.

vojtechkral commented 5 years ago

@Fabbi Brilliant, thanks! Yes, my build has just failed because of the relative path. Looks like it indeed needs to be absolute, on my end it wouldn't work no matter to what base it was relative.

Edit: I probably won't be implementing that CMakeLists.txt patch because the prefix path can also come from the environment. Which could be accounted for of course, but it would make the script quite complex, it's probably easier to just give a clear instruction to specify the prefix as absolute.

Fabbi commented 5 years ago

it's probably easier to just give a clear instruction to specify the prefix as absolute.

I agree.

PatrikTheDev commented 5 years ago

@Fabbi could you post your CMakeLists.txt? I am little bit lazy to do all these changes

vojtechkral commented 5 years ago

@Patrik-svobodik Don't do any changes. Just perform the step 3. again, I have edited my comment and added the $PWD in there which should ensure correct prefix path.

vojtechkral commented 5 years ago

I have also written down a doc/tutorial for Mac and I'll be publishing it soon. Edit: Merged in master now.

vojtechkral commented 5 years ago

It looks like with recent Slic3r and recent wxWidgets you can build against new(er) SDKs just fine and even stuff like dark mode seems to work. I have simplified the tutorial accordingly, there should be no need to download and set older SDK.

thenickdude commented 5 years ago

Thanks for the new version! For some reason when I build the dependencies it detects my 10.14 SDK properly:

OS X SDK Path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
OS X Deployment Target (inferred from default): 10.14

But then when I cmake the main project, it detects 10.9 instead, and so fails when it tries to use features found in newer versions:

-- Mac OS deployment target (SDK version): 10.9

...

[ 26%] Building CXX object src/libslic3r/CMakeFiles/libslic3r.dir/pchheader.cpp.o
In file included from /Users/nick/Slic3r2/src/libslic3r/pchheader.cpp:1:
In file included from /Users/nick/Slic3r2/src/libslic3r/pchheader.hpp:99:
/opt/local/include/tbb/task_group.h:132:53: error: 'uncaught_exceptions' is unavailable: introduced in macOS 10.12
            bool stack_unwinding_in_progress = std::uncaught_exceptions() > 0;
                                                    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:130:63: note: 'uncaught_exceptions' has been explicitly
      marked unavailable here
_LIBCPP_FUNC_VIS _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS int uncaught_exceptions() _NOEXCEPT;

It looks like I have to explicitly choose 10.14 when I call cmake for the main project like so:

cmake .. -DCMAKE_PREFIX_PATH="$PWD/../deps/build/destdir/usr/local" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14

Then it does build successfully. Is this expected behaviour?

bubnikv commented 5 years ago

Congrats, you are likely the first person in the known universe, who managed to compile any version of any Slic3r on OSX.

On Fri, Jan 11, 2019 at 7:45 AM Nicholas Sherlock notifications@github.com wrote:

Thanks for the new version! For some reason when I build the dependencies it detects my 10.14 SDK properly:

OS X SDK Path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk OS X Deployment Target (inferred from default): 10.14

But then when I cmake the main project, it detects 10.9 instead, and so fails when it tries to use features found in newer versions:

-- Mac OS deployment target (SDK version): 10.9

...

[ 26%] Building CXX object src/libslic3r/CMakeFiles/libslic3r.dir/pchheader.cpp.o In file included from /Users/nick/Slic3r2/src/libslic3r/pchheader.cpp:1: In file included from /Users/nick/Slic3r2/src/libslic3r/pchheader.hpp:99: /opt/local/include/tbb/task_group.h:132:53: error: 'uncaught_exceptions' is unavailable: introduced in macOS 10.12 bool stack_unwinding_in_progress = std::uncaught_exceptions() > 0; ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:130:63: note: 'uncaught_exceptions' has been explicitly marked unavailable here _LIBCPP_FUNC_VIS _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS int uncaught_exceptions() _NOEXCEPT;

It looks like I have to explicitly choose 10.14 when I call cmake for the main project like so:

cmake .. -DCMAKE_PREFIX_PATH="$PWD/../deps/build/destdir/usr/local" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14

Then it does build successfully. Is this expected behaviour?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/1421#issuecomment-453396145, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5IxH16hypkTeJetpFir1OUJwijpqpks5vCDLzgaJpZM4Yt0fm .

vojtechkral commented 5 years ago

@thenickdude Is it possible there was a cache entry from the past in your main build? You can try removing the CMakeCache.txt file and running cmake afresh to see if the SDK is set wrong again. I can't think of a reason why the SDK default should be different in the two CMake projects...

Nope, there's a bug, will fix...

vojtechkral commented 5 years ago

@thenickdude Should be fixed now, thanks for the feedback :)

PatrikTheDev commented 5 years ago

@vojtechkral hi, I compiled it succesfully but where is the executable? I don't see any anywhere

vojtechkral commented 5 years ago

@Patrik-svobodik The binary is at build/src/slic3r-gui . I should probably add this to the guide...

PatrikTheDev commented 5 years ago

@vojtechkral good, I see the dark mode works pretty well, but one more thing, how to pack it as a .app file? I am not very experienced with C++

vojtechkral commented 5 years ago

@Patrik-svobodik I honestly don't know/remember the details as to how that's done. You can have a look at the eixsting Slic3r app bundles or find a guide online, I'm sure there's something out there...

PatrikTheDev commented 5 years ago

@vojtechkral oh really? I got an idea, I can replace the files of the slic3r PE that you released

PatrikTheDev commented 5 years ago

@vojtechkral nope, did not work, how the hell do you pack it as a .app?

Fabbi commented 5 years ago

@Patrik-svobodik it should work by replacing the file as long as the name is the same. There is a Info.plist in the Slic3r.app/Contents with a key CFBundleExecutable which tells the App which binary under Slic3r.app/Contents/MacOs to execute.

So I would guess you need to replace the Slic3r.app/Contents/MacOs/Slic3r and Slic3r.app/Contents/MacOs/local-lib and it should work.

PatrikTheDev commented 5 years ago

@Fabbi for some reason when I tried again it worked flawlessly