Unable to load STEP files

[smcbride-ca]

What happened?

Expected result: STEP file opens
Result:
Cannot load OCCTWrapper.so: /tmp/.mount_SuperSmadyUY/bin/OCCTWrapper.so: cannot open shared object file: No such file or directory when trying to load a STEP file.

Project file & How to reproduce

bug_report.zip
pad.step.zip

Load any STEP file

Version

2.5.59.2

Operating system

Arch Linux

Printer model

Anycubic Vyper

[eduncan911]

just ran into this as well (first time importing a STEP).

Same versions as the OS, except I'm on debian.

Using AppImage.

[eduncan911]

I suspect the appimage was built without OCCT and it's expected for us to install. There's some weirdness with licenses with OCCT too. But FreeCAD gets around it somehow (i've also heard they dont care).

[VaiOnko]

I'm having the same problems here. I'm on Arch and installed the prerelease from the AUR which uses the Appimage.

[torriem]

I can't find any information online anywhere on even how to build OCCTWrapper.so. It's not in any Fedora or Debian repo that I can find. Is it something to do with Python bindings for OCCT?

[StefanClementz]

I have the same issue on Ubuntu, both 20.04 LTS and 22.04.2 LTS. built OCCT and now superslicer crashes when i load a step-file rather than just give me the error message above.

Not sure what to do either.

[Tau512]

Not sure what to do either.

i too have hit the same issue (F37 + arachne ubuntu gtk2 appimage). I encountered a model that was .step only. turns out you can import .step's into freecad, and then export as stl/3mf and slice as normal. I know it's not the same as .step, but if thats your only option then it's better than nothing till it's fixed.

I suspect the appimage was built without OCCT and it's expected for us to install. There's some weirdness with licenses with OCCT too. But FreeCAD gets around it somehow (i've also heard they dont care).

seems it's linux specific but i guess that still means it could be licencing. i've a zip extract of the win64 release; OCCTWrapper.dll is present so i assume it works on that platform

[vkhodygo]

@supermerill Do you mind pointing towards the right direction? I could try and give it a go.

[supermerill]

I guess I need to add an OCCTWrapper.so somewhere in the appimage.
has to check where I can grab it (is it compiled or do i need to get it from occt) and then where to put it inside the appimage to makes it work.

[jmickelin]

The code for OCCTWrapper is already in this repo (https://github.com/supermerill/SuperSlicer/tree/nightly_dev/src/occt_wrapper) and seems to have been merged from the upstream project at the same time that the STEP importing stuff. The compiled library just isn't included in the AppImage. Mimicking what PrusaSlicer is doing to compile it and bundle it in their AppImage is probably the way to go.

I can't find any information online anywhere on even how to build OCCTWrapper.so. It's not in any Fedora or Debian repo that I can find. Is it something to do with Python bindings for OCCT?

It's part of SuperSlicer/PrusaSlicer itself. You can find a compiled version of it by extracting it from the PrusaSlicer AppImage release. It seems to be statically linked against the OpenCascade stuff, and the STEP import code uses dlsym to resolve the needed symbols at runtime, so in theory you should be able to transplant this into (a copy of) the AppImage filesystem's bin/ directory and get it to work. I got a segfault when trying this, however, which I didn't investigate further. But again, there is no reason to not compile it from scratch, especially if the alternative is to rip out a precompiled version from elsewhere (which wouldn't make a difference with regards to any potential licensing issues related to the static linking).

Note: It's been a while since I investigated this and only now noticed that I had this whole comment typed out and auto-saved by Github, because I never posted it, for whatever reason. This was before @supermerill's latest comment and acknowledgement above, but the conclusion still holds.

[jmickelin]

Interestingly, it seems that upstream PrusaSlicer had this same bug in one of their pre-2.5.0 AppImage releases (on ARM).

Unfortunately, the fix was somewhere in their own CI config (whose repo is not public, as far as I know). But since there does not seem to be any follow-up commits affecting relevant parts of the CMake scripts (as far as I could tell) between PS 2.5.0-beta1 and 2.5.0-rc1 (where the bug had been fixed, according to release notes), that does narrow it down quite a bit. That is, if upstream experienced the problem, the bug appearing in SuperSlicer might not be caused by any of the changes to the existing CMake scripts done in this fork.

It also explains how it can still be broken here, despite merging a way later release (i.e. the final 2.5.0 one) than the one where it originally appeared and where it was fixed.

In fact, I believe this is where the problem lies:

SuperSlicer/src/platform/unix/BuildLinuxImage.sh.in

Line 38 in 898a4af

cp -f src/@SLIC3R_APP_CMD@ package/bin/@SLIC3R_APP_CMD@

The build script only copies the main binary explicitly, so any additional build artefacts (outside of resources/) are missed. An immediate fix would be to add another explicit cp for the OCCTWrapper.so library (which, reading through src/occt_wrapper/CMakeLists.txt, should end up in the ${CMAKE_BINARY_DIR}/src build directory, which I suppose is right next to the main binary). (I have not tested this myself: The last time I tried to compile PrusaSlicer on this machine, things started smoking 😉 )

While this ticket is only for Linux AppImages, I noticed that the corresponding build files for the other platforms also just copy the main executable explicitly. So I imagine a similar change is needed there too (with .so changed to .dll or .dylib or whatever they use).

That said - and forgive me yak shaving from the sidelines when I'm not even working on a PR myself - I think the approach done by the DaveK build scripts (mentioned in the upstream ticket I linked to above) is a lot more sensible: https://github.com/davidk/PrusaSlicer-ARM.AppImage/blob/version_2.5.0-beta1/AppImageBuilder-aarch64-full.yml#L45

DESTDIR=AppDir cmake --build ./ --target install -j $(nproc)

That is, run the full cmake install target (while overriding DESTDIR to the one which will be bundled by the AppImage builder). That way, the actual cmake scripts serve as the single source of truth for what resources are needed to run the program, and you will not risk missing any new dependencies added in upstream. Especially now that it's clear that some of the build changes may slip by unnoticed if you just go by the Git log, since the two projects use different build setups.

EDIT (2024-06-03): Looks like it's actually successfully bundled into the Windows release, and moreover it's statically compiled on MacOS, so ignore what I said about that above: prusa3d@aff3370

[jmickelin]

@supermerill Thanks for the work you've done so far!

However, I tried out the latest release and I still get the same error. Checking the AppImage (SuperSlicer-ubuntu_20.04-gtk2-2.5.59.11.AppImage --appimage-extract), the .so is nowhere to be found.

I noticed that the build script is missing a set -euo pipefail in the beginning, so Bash would silently ignore errors instead of aborting. I think this could explain why it still generated the AppImage as a build artifact. The resulting error message once enabled might also help figure out what went wrong (I suspect it could be that the path I speculated it's at was wrong).

I double checked both AppImage versions and also the (zipped) tarball, just to make sure.

[supermerill]

oups, forgot to build it before copying it

[jmickelin]

Awesome! Thank you. Can confirm it works in 2.5.59.12 :)

[torriem]

Sorry but it's still not working on Fedora 40 with the 2.5.60 AppImage. Same error about the missing file.

[supermerill]

silly me. thanks for hte report. will be in next nightly.