C Extension Load error after installing new RBZ over old one SketchUp 2022 M1

I wonder if I’m the first to discover this issue since probably not many developers have likely tested installing a new extension over top of an old one on SU2022 M1 Macs.

I was about to release Profile Builder 3.3.0 which is tested and working fine on M1 Macs SU2022.

However, if install the RBZ for 3.3.0 while an older version is currently installed (like the current public version 3.2.2), I get a strange load error after restarting SketchUp 2022. This load error only seems to disappear after I reboot my Mac! After rebooting, PB 3.3.0 loads fine without errors. Below is the load error.

*Error: #<LoadError: dlopen(/users/dalemartens/library/application support/sketchup 2022/sketchup/plugins/dm_profilebuilder3/so/bundle/2.7/MSS_Licensing.bundle, 0x0009): tried: ‘/users/dalemartens/library/application support/sketchup 2022/sketchup/plugins/dm_profilebuilder3/so/bundle/2.7/MSS_Licensing.bundle’ (fcntl(fd, F_ADDFILESIGS_RETURN) failed with errno=37, sliceOffset=0x00044000, codeBlobOffset=0x0003EE40, codeBlobSize=0x00004F40 for ‘/Users/dalemartens/Library/Application Support/SketchUp 2022/SketchUp/Plugins/DM_ProfileBuilder3/so/bundle/2.7/MSS_Licensing.bundle’)

This is how I can reproduce the error:

@thomthom any ideas?

I can make it happen with the steps you gave. We should tag @Hilliard_Scott as well.

I think this can happen on Windows if a DLL is loaded. Windows will not let it be overwritten.

So, I think the normal scenario of updating extensions with binaries should be to disable the old version from the Extension Manager, restart SketchUp so that the extension’s binaries do not load, and then do the update. We (in the community) have always recommended users restart SketchUp after installing extensions. In this update scenario, the updated extension can be reenabled before the restart if the install did not enable it.

Are you thinking that if something like that can happen on Windows, it might happen on Mac as well?

One other thing to know is that if SketchUp is set to run in Rosetta on an M1 Mac, the problem doesn’t happen. The upgrade of the Intel based code doesn’t cause a problem, but upgrading from Intel to Universal does show a problem if you are running as ARM64.

Not in that general sense. I’m referring to security where a system can prevent a library in use from being overwritten to prevent malware.

It wouldn’t surprise me that the Ruby context would need to be fully unloaded and reloaded with 2022, the dylibs and headers are now ‘fat’ for M1 architecture. Dll’s can be side-by-side, I don’t think dylibs can.

To workaround that, we use a staging pattern. The installed dll lives in a ‘stage’ folder and is never directly loaded by our extension. Our Ruby code copies the dll in another folder before loading it.
Therefore a new version can overwrite the old one, but it requires a SketchUp restart to be loaded.

Maybe a similar pattern would work in your case, Dale?


Yes, I’ve been using the staging pattern for Windows for years but not on Mac as it wasn’t needed.

However, I just tried using the staging pattern you mentioned on Mac and it does seem to fix the issue I described so that’s good!

It is still confusing for me why it would work after rebooting but not after simply restarting SketchUp. Can anyone explain that to me?

1 Like