SDK tests are not running on MacBook Pro M1 #1506
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Oct 19, 2022
…pdate` This stops the usage of Scripts/carthage-with-workaround-for-issue-3019.sh when building the project’s dependencies using Carthage for local development (i.e. when running `make update` or one of its sub-commands). This file was seems to have been originally introduced to fix an error related to duplicate architectures when running Carthage. I don’t get any errors switching back to plain Carthage without a wrapper when running `make update` on my M1 Pro machine, using Carthage 0.38.0. Given that the linked issue Carthage/Carthage#3019 is now marked as resolved, I guess something was changed in Carthage that resolves this for us 🤷. This closes #1506, where we were seeing "Undefined symbol: _OBJC_CLASS_$_ARTDeltaCodec" errors running `make test_iOS` on M1* machines. I guess in the part of the script where we exclude ARM architectures (I don’t exactly know what that means) we had stopped building something that we needed to run on the current platform. We’re still using this file for the `make carthage_package` task. We should check whether we need it there too, but since that might have user-facing consequences (instead of just breaking our development environment) I don’t want to do that hastily. I’ve created a separate issue #1509 for that.
lawrence-forooghian
added a commit
that referenced
this issue
Oct 20, 2022
…pdate` This stops the usage of Scripts/carthage-with-workaround-for-issue-3019.sh when building the project’s dependencies using Carthage for local development (i.e. when running `make update` or one of its sub-commands). This file was seems to have been originally introduced to fix an error related to duplicate architectures when running Carthage. I don’t get any errors switching back to plain Carthage without a wrapper when running `make update` on my M1 Pro machine, using Carthage 0.38.0. Given that the linked issue Carthage/Carthage#3019 is now marked as resolved, I guess something was changed in Carthage that resolves this for us 🤷. This closes #1506, where we were seeing "Undefined symbol: _OBJC_CLASS_$_ARTDeltaCodec" errors running `make test_iOS` on M1* machines. I guess in the part of the script where we exclude ARM architectures (I don’t exactly know what that means) we had stopped building something that we needed to run on the current platform. We’re still using this file for the `make carthage_package` task. We should check whether we need it there too, but since that might have user-facing consequences (instead of just breaking our development environment) I don’t want to do that hastily. I’ve created a separate issue #1509 for that.
lawrence-forooghian
added a commit
that referenced
this issue
Oct 24, 2022
…pdate` This stops the usage of Scripts/carthage-with-workaround-for-issue-3019.sh when building the project’s dependencies using Carthage for local development (i.e. when running `make update` or one of its sub-commands). This file was seems to have been originally introduced to fix an error related to duplicate architectures when running Carthage. I don’t get any errors switching back to plain Carthage without a wrapper when running `make update` on my M1 Pro machine, using Carthage 0.38.0. Given that the linked issue Carthage/Carthage#3019 is now marked as resolved, I guess something was changed in Carthage that resolves this for us 🤷. This closes #1506, where we were seeing "Undefined symbol: _OBJC_CLASS_$_ARTDeltaCodec" errors running `make test_iOS` on M1* machines. I guess in the part of the script where we exclude ARM architectures (I don’t exactly know what that means) we had stopped building something that we needed to run on the current platform. We’re still using this file for the `make carthage_package` task. We should check whether we need it there too, but since that might have user-facing consequences (instead of just breaking our development environment) I don’t want to do that hastily. I’ve created a separate issue #1509 for that.
lawrence-forooghian
added a commit
that referenced
this issue
Oct 31, 2023
…pdate` This stops the usage of Scripts/carthage-with-workaround-for-issue-3019.sh when building the project’s dependencies using Carthage for local development (i.e. when running `make update` or one of its sub-commands). This file was seems to have been originally introduced to fix an error related to duplicate architectures when running Carthage. I don’t get any errors switching back to plain Carthage without a wrapper when running `make update` on my M1 Pro machine, using Carthage 0.38.0. Given that the linked issue Carthage/Carthage#3019 is now marked as resolved, I guess something was changed in Carthage that resolves this for us 🤷. This closes #1506, where we were seeing "Undefined symbol: _OBJC_CLASS_$_ARTDeltaCodec" errors running `make test_iOS` on M1* machines. I guess in the part of the script where we exclude ARM architectures (I don’t exactly know what that means) we had stopped building something that we needed to run on the current platform. We’re still using this file for the `make carthage_package` task. We should check whether we need it there too, but since that might have user-facing consequences (instead of just breaking our development environment) I don’t want to do that hastily. I’ve created a separate issue #1509 for that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was trying to test Ably Cocoa SDK as it's described in
CONTRIBUTING.mdwhich means I run:The second command is failing. It looks like it's related to the ARM M1 processor in MacBook Pro. I was able to fix it by removing
arm64fromScripts/carthage-with-workaround-for-issue-3019.sh, line 14, but it needs to be confirmed that it's not affecting other issues.Full output is:
┆Issue is synchronized with this Jira Uncategorised by Unito
The text was updated successfully, but these errors were encountered: