Arch Linux User Repository

@whoops you may also want to remove the qhull patch. The issue was fixed in qhull 2020.2-4.

Does cmake detect wxWidgets now if not both gtk2 and gtk3 are installed?

superslicer-git builds and sort of runs with https://github.com/archlinux/svntogit-community/blob/packages/prusa-slicer/trunk/prusa-slicer-openexr3.patch applied.

edit:

Stole some lines from superslicer-git:

https://pastebin.com/6SqEFyD0

local/prusa-slicer-git 2.4.0.alpha0.r230.gc414f932d-1

builds fine, runs fine, printed one thing fine.

Started it with

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/wxgtk-dev/lib prusa-slicer

There's probably a better way to do this.

I am using wxgtk3-dev-opt for superslicer (a fork of prusaslicer). May this is a option for prusaslicer too.

~~But I did not have a solution for OpenEXR.~~

Managed to build some 4+ versions recently, totally wasn't worth it and it doesn't look good. Several problems:

Even the ones previously built won't run with openexr 3 and I guess they aren't expected to build or run with openexr 3 until prusa upgades? Not sure that's going to happen soon, sounds like a "porting guide" has yet to be written? https://github.com/AcademySoftwareFoundation/openexr/issues/900

Also prusa slicer does not build with wxgtk < 3.1, it does not build with some wxgtk-dev versions and with wxgtk-dev above 3.4 it builds but it segfaults due to glew errors or something (or other render stuff, made a bit of a mess and rushed through it, but everything looks broken).

Did not manage to get static build working. Read somewhere, prusa is maintaining a special version of wxgtk 3.1 with backports as well as other libraries. That seems like it might be one possible workaround for both dynamic library problems. There's problems with tbb not being found, needed to add -DTBB_LIBRARIES=/usr/include/tbb to the build options. But then I ran into some weird xrendr issues again, then Half wasn't found yet again and I'm not sure if static libraries are working at all or if that option just made things worse, so I stopped.

So long story short: Can't really create issues on prusa github since I made to much of a mess and at this point have no idea what's going on exactly. Maybe everything is broken, maybe I broke everything else while failing to fix 2 things. Either way, I'm going to have to downgrade prusaslicer because the openexr update is kind of hard to roll back without restoring the whole system from a backup.

Downgraded to stable 3.5 for now. Crashed initially, had to change one occurrence of "marlinfirmware" in ~/.config/PrusaSlicer/vendor/PrusaResearch.ini to just "marlin", after that prusaslicer needs "reconfiguring" but as far as I can tell it retained all of my settings (except I had to re-add the octoprint connection).

In libOpenEXR 3 libIlmImf was renamed to libOpenEXR and moved to the imath package. The header were not changed, and are now included by OpenEXR via a CMakes. I am not sure why this does not work.

https://github.com/AcademySoftwareFoundation/openexr/blob/master/CHANGES.md#version-301-april-1-2021

Hi. It fails for me with

-- Found CURL: /usr/lib/libcurl.so (found version "7.76.1") 
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11") 
-- Found Eigen3: /usr/include/eigen3 (Required is at least version "3.3") 
-- Found EXPAT: /usr/lib/libexpat.so (found version "2.3.0") 
-- Found PNG: /usr/lib/libpng.so (found version "1.6.37") 
-- Found OpenGL: /usr/lib/libOpenGL.so   
-- Found GLEW: /usr/include (found version "2.2.0") 
-- Found NLopt in '/usr/lib'.
-- Using NLopt include directory '/usr/include'.
-- Using NLopt library '/usr/lib/libnlopt.so'.
-- Found OpenVDB: /usr/include (found suitable version "8.0.1", minimum required is "5.0") found components: openvdb 
-- OpenVDB ABI Version: 8
CMake Error at cmake/modules/FindOpenVDB.cmake:322 (message):
  IlmBase::Half can not be found!
Call Stack (most recent call first):
  cmake/modules/FindOpenVDB.cmake:346 (just_fail)
  CMakeLists.txt:496 (find_package)

Same with superslicer-git.

@nekonoor @Salamandar for information, there is a duplicate of this issue in the upstream issue tracker ( https://github.com/prusa3d/PrusaSlicer/issues/6421 ).

For now the only proposed solution is to build with static libraries, so I hope someone will figure out a cleaner fix.

i was the one who posted that comment.

that workaround does result in a working prusaslicer installation, but it is just compiling an old commit, so you won't get any of the features introduced after that commit. (which as mentioned in the github issue is 991fa67fd1e71dad6d2d5d10fc6e98ba714f8a9f, from march 24th)

i can't really seem to figure out what the issue is so i hope it will be looked into by someone more knowledgeable soon.

Workaround found upstream: https://github.com/prusa3d/PrusaSlicer/issues/6270

@j12t You should report that upstream. @GelatinousSlime true ! Will fix that.