We value your input!
Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey

Archicad C++ API
About Archicad add-on development using the C++ API.

OSX - Outdated AddOn error - Apple silicon / Intel - Different AC 26 builds & different OSX versions

dushyant
Enthusiast

Hello,

I am trying to compile an addon for Archicad 26 on OSX. I built it on two different machines, for AC 26, but different OSX versions and one having Intel chip and the other M1. Both built as Release versions using CMake and the MDID identifiers are unique and valid.

Archicad 26 versions:

Intel mac: Build 4019 (Latest update)

Apple silicon: Build 4024

 

The problem is that the addon built on either machine works on the one it was compiled on, but not on the other. It gives this error: "The file is an outdated Add-On that cannot be used with this Archicad version."

 

https://archicadapi.Graphisoft.com/faq <--- This page talks about some "manifest" file. Where is it in the API for AC26?

 

Do the warnings during the 'compile' process affect the loading of the addon? But then it should not load on all the machines including the one that it was compiled on.

 

Does anyone have any idea why this could be happening?

 

Thanks.

 

 

 

 

12 REPLIES 12
Barry Kelly
Moderator

As far as I know separate add-ons need to be created for Mac Intel and Mac Silicon.

The same as a different add-on needs to be created for Windows as well.

So there are now 3 versions add-on need to be compiled for.

 

Barry.

One of the forum moderators.
Versions 6.5 to 27
i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10
Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11

I see. 

By the way, the addon compiled on intel-mac, does not load on another intel-mac with the same Archicad 26 version (Build 4019). It gives the same error: "The file is an outdated Add-On that cannot be used with this Archicad version." Why is that?

 

Hi!

If you don't specify which architecture to compile for, the compiler likely selects the architecture it runs on. So for the Intel chip it would likely build for x86_64 architecture and for the M1 chip it builds for arm64 or maybe it makes a so called 'fat binary' where both architectures are present.
If that's the case for your project too, then it makes sense that it would only run on the one which it was compiled on.
Maybe it would be possible to make a fat binary which works on both, but I haven't found success in that and it seems saver to compile two versions anyway.
You can check the architecture of the compiled executables with something like this:

 

$ lipo -info out/build/ac26-mac-arm/Release/Save\ Layer\ Settings.bundle/Contents/MacOS/Save\ Layer\ Settings 
Non-fat file: out/build/ac26-mac-arm/Release/Save Layer Settings.bundle/Contents/MacOS/Save Layer Settings is architecture: arm64

$ lipo -info out/build/ac26-mac-x64/Release/Save\ Layer\ Settings.bundle/Contents/MacOS/Save\ Layer\ Settings 
Non-fat file: out/build/ac26-mac-x64/Release/Save Layer Settings.bundle/Contents/MacOS/Save Layer Settings is architecture: x86_64

For cmake you can check out CMAKE_OSX_ARCHITECTURES. Specifying this correctly allows me to build both the x86_64 and arm64 builds on the same machine.
Hope this helps!
Bernd

 

 

Hi Bernd, that command did output arm64 and x86_x64 respectively for M1 and intel-mac. I don't mind compiling different versions for both.

So keeping that out of the way now, do you have any idea why the intel-mac binary is giving the same error ("The file is an outdated Add-On that cannot be used with this Archicad version.") when tried on another intel-mac with the same AC 26 ver.?

Also, any idea about any 'manifest' file in the addon source?

Thanks.

For macOS I would say that maybe with 'manifest' file they mean the 'RFIX.mac/Info.plist' file. (Although in the link you provided it seems to me that they are specifically talking about a manifest file for Windows builds. But the info partially quite outdated since it mentions VS2010).
There's one point in the Info.plist file which I try to keep as consistent as possible:

 

<key>LSMinimumSystemVersion</key>
<string>10.15.0</string>

 

Then I specify also the following variables:
https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html

 

set (CMAKE_OSX_DEPLOYMENT_TARGET "10.15")
set (CMAKE_XCODE_ATTRIBUTE_MACOSX_DEPLOYMENT_TARGET ${CMAKE_OSX_DEPLOYMENT_TARGET})

 


Also are you notarizing your build? This could be another issue why it's not accepted on a different mac. You can find more information here: https://archicadapi.Graphisoft.com/notarizing-add-ons-for-macos-catalina
Although again some parts are outdated I think.


Unfortunately compiling/notarizing Add-Ons for macOS was always quite a fight for me and it takes several hours/days every few months when it stops working once again.

Best,
Bernd

Thanks for that info!

I haven't notarised the addon, but I did try making another addon to test, and shared it, and it worked on the other system! So now I don't think it should be related to notarisation / MDID / AC build ver.

I don't use XCode, so perhaps CMAKE_XCODE_ATTRIBUTE_MACOSX_DEPLOYMENT_TARGET is not relevant.

LSMinimumSystemVersion is set to 10.11.0, which is not my OS ver. The other machine is of a higher macos ver. than the development machine.
 

For the addon in question, the compile process does raise some warnings. Do these warnings somehow affect the resulting binary's portability?

I'm really clueless now about this persistent message: "The file is an outdated Add-On that cannot be used with this Archicad version."

:S

 

Which generator are you using then for cmake on macOS if you are not using XCode? I'm interested to try others as well 🙂

LSMinimumSystemVersion is only a lower limit of OS version a user must have to run the project. I set it to 10.15 for AC26 builds since the AC26 development kit has this same lower limit. This should ensure that everybody who can run AC26 can also run your Add-On.

Regarding the warnings, it depends a lot on the specific warnings. I think it would be possible that some warnings could affect the portability. So please post a selection of the warnings or append a log-file so we can have a closer look.

dushyant
Enthusiast

I'm using vscode with Clang-13.0.0 (Clang seems to be available on the system due to XCode). LSMinimumSystemVersion is set in Info.plist to 10.11.0. So far I didn't feel the need to set that in CMake too.

 

The warnings are for the deprecated 'sprintf', etc. in some library files, like these:

[build] clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
[build] warning: unknown warning option '-Wnoerror'; did you mean '-Wnoderef'? [-Wunknown-warning-option]

'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]

 

 

 



I'm using vscode with Clang-13.0.0 (Clang seems to be available on the system due to XCode). LSMinimumSystemVersion is set in Info.plist to 10.11.0. So far I didn't feel the need to set that in CMake too.


I think it would be worth a shot to set it everywhere to 10.15.0 / 10.15. I think I had issues in the path where these were not matching to the Archicad SDK. And if you are using clang from XCode, it might still be, that also the XCode variables would have an effect.

 


The warnings are for the deprecated 'sprintf', etc. in some library files, like these:

[build] clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
[build] warning: unknown warning option '-Wnoerror'; did you mean '-Wnoderef'? [-Wunknown-warning-option]

'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]


I have similar warnings for 'sprintf' and ignoring it didn't seem to be an issue for compatibility. (I use "-Wno-deprecated-declartions" for it.
'-Wnoerror' seems like you use this flag which is not existing. So removing it should get rid of the error message. Maybe you just wanted to remove "-Werror"?