While building out folder we are facing a issue in MAC #16759

Rajashreekalmane · 2022-03-29T09:21:12Z

Problem

With commitID(58cd5fb) we are facing this issue while trying to built out folder in MAC i,e.,
" ld: symbol(s) not found for architecture x86_64"
Steps to reproduce :

git clone https://github.com/project-chip/connectedhomeip.git
cd connectedhomeip
source scripts/bootstrap.sh
source scripts/activate.sh
cd examples/chip-tool
gn gen out/debug --args='chip_mdns="platform" chip_inet_config_enable_ipv4=false'
ninja -C out/debug

The text was updated successfully, but these errors were encountered:

bzbarsky-apple · 2022-03-30T15:48:08Z

The issue is here:

ld: warning: ignoring file /opt/homebrew/Cellar/openssl@3/3.0.1/lib/libssl.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file /opt/homebrew/Cellar/openssl@3/3.0.1/lib/libcrypto.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64

Presumably this is an M1 mac, hence the installed library is arm64?

Why is this building for macOS-x86_64 then?

We should either fix to detect the right CPU type in the build system, or you might need to install the x86-64 version of openssl if this should really produce an x86-64 binary.

ReneJosefsen · 2022-04-04T21:33:11Z

I was looking a bit into this and as far as I can figure out this seems to be an "issue" with gn. It seems like it is only able to return "x86" or "x64" as the host_cpu (which is typically used to set the current_cpu), so my MacBook Pro M1 has the current_cpu set to x64. So, in the build/config/mac/mac_sdk.gni this results in the target_cpu being set to "x86_64". I tried to look at the gn help to see if I could find a clean way to determine if it is a arm64 based device, but I have not been able to find any.

As mentioned, installing the x86_64 homebrew and use that to install openssl and pkg-config also works since it then uses x86_64 versions of the libs.

Alternatively I noticed it was possible to pass arguments to the build script, so by using this command I was able to get it to build on my M1 Mac.

scripts/examples/gn_build_example.sh examples/chip-tool out/chip-tool/ 'current_cpu="arm64"' 'mac_deployment_target="12.0"'

I also tested by simply overriding the values in the mac_sdk.gni, forcing the mac_target_arch to "arm64", which also worked fine if you do not want to add the args every time.

Note: I bumped the deployment target as well to get rid of warnings that the libs was built for 12.0 but being linked to 11.0. It might work without that part, not sure.

bzbarsky-apple · 2022-04-05T19:12:28Z

@mspang Any idea what should be happening here on the gn end?

xylophone21 · 2022-04-06T10:06:12Z

I was looking a bit into this and as far as I can figure out this seems to be an "issue" with gn. It seems like it is only able to return "x86" or "x64" as the host_cpu (which is typically used to set the current_cpu), so my MacBook Pro M1 has the current_cpu set to x64. So, in the build/config/mac/mac_sdk.gni this results in the target_cpu being set to "x86_64". I tried to look at the gn help to see if I could find a clean way to determine if it is a arm64 based device, but I have not been able to find any.

As mentioned, installing the x86_64 homebrew and use that to install openssl and pkg-config also works since it then uses x86_64 versions of the libs.

Alternatively I noticed it was possible to pass arguments to the build script, so by using this command I was able to get it to build on my M1 Mac.

scripts/examples/gn_build_example.sh examples/chip-tool out/chip-tool/ 'current_cpu="arm64"' 'mac_deployment_target="12.0"'

I also tested by simply overriding the values in the mac_sdk.gni, forcing the mac_target_arch to "arm64", which also worked fine if you do not want to add the args every time.

Note: I bumped the deployment target as well to get rid of warnings that the libs was built for 12.0 but being linked to 11.0. It might work without that part, not sure.

But do you know why it works well on M1 one week ago?

ReneJosefsen · 2022-04-06T10:44:10Z

Not sure, I seem to remember that homebrew was updated at some point during this process, somy setup might have changed from having the the x86_64 variant of openssl to the the arm64 version.

To be honest, I do not know why this suddenly broke, but I was not able to go back to older commits, which I know has worked previously. So I strongly assume this is something that changed in my setup and not in the repo.

xylophone21 · 2022-04-06T11:06:34Z

FYI,
a20ba1c this commit works well on M1
and when I update to 7dede20, seems bootstrap.sh system upgraded, so I got below erros

ERROR at //third_party/connectedhomeip/third_party/pigweed/repo/pw_toolchain/host_clang/BUILD.gn:16:1: Unable to load "/Users/lihui/Code/matter/connectedhomeip/examples/tv-app/android/build_overrides/pigweed_environment.gni".
import("//build_overrides/pigweed_environment.gni")
^-------------------------------------------------
See //third_party/connectedhomeip/build/config/compiler/BUILD.gn:286:7: which caused the file to be included.
      "$dir_pw_toolchain/host_clang:no_system_libcpp",
      ^----------------------------------------------

then I remove .environment folder and bootstrap.sh again, I got this issue

ReneJosefsen · 2022-04-06T11:12:23Z

Sounds very familiar. We had two MacBooks which also reported an issue on pigweed and the solution we ended up with was also to remove the .enviroment folder and re-bootstrap, so maybe there is some changes in the bootstraping process that is now causing issues with Apple Silicon?

Actually a20ba1c was also one of the commits that I used to sanity check, since I know it was working earlier, but it did not work for me afterwards. I might not have properly bootstrapped it after having checked it out, hence why it was not working. Did you remove the .enviroment folder when jumping back?

xylophone21 · 2022-04-06T11:19:09Z

No, I have two workspaces, but the old commit id does not work also now with below errors. And I am re-bootstrap that now

Traceback (most recent call last):
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/plugins.py", line 87, in from_name
    module = importlib.import_module(module_name)
  File "/opt/homebrew/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 850, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_watch/py/pw_watch/watch.py", line 72, in <module>
    import pw_console.python_logging
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_console/py/pw_console/__init__.py", line 16, in <module>
    from pw_console.embed import PwConsoleEmbed
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_console/py/pw_console/embed.py", line 23, in <module>
    from pw_console.console_app import ConsoleApp
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_console/py/pw_console/console_app.py", line 61, in <module>
    from pw_console.log_pane import LogPane
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_console/py/pw_console/log_pane.py", line 41, in <module>
    from prompt_toolkit.mouse_events import MouseEvent, MouseEventType, MouseButton
ImportError: cannot import name 'MouseButton' from 'prompt_toolkit.mouse_events' (/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/.environment/pigweed-venv/lib/python3.9/site-packages/prompt_toolkit/mouse_events.py)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/.environment/pigweed-venv/bin/pw", line 33, in <module>
    sys.exit(load_entry_point('pw-cli', 'console_scripts', 'pw')())
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/__main__.py", line 41, in main
    pw_command_plugins.register(args.directory)
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/pw_command_plugins.py", line 59, in register
    _register_builtin_plugins(_plugin_registry)
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/pw_command_plugins.py", line 39, in _register_builtin_plugins
    registry.register_by_name('watch', 'pw_watch.watch', 'main')
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/plugins.py", line 261, in register_by_name
    Plugin.from_name(name, module_name, member_name, source))
  File "/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/third_party/pigweed/repo/pw_cli/py/pw_cli/plugins.py", line 89, in from_name
    raise Error(f'Failed to import module "{module_name}"') from err
pw_cli.plugins.Error: Failed to import module "pw_watch.watch" (ImportError: cannot import name 'MouseButton' from 'prompt_toolkit.mouse_events' (/Users/lihui/Code/matter/droidmattertvserver/third_party/connectedhomeip/.environment/pigweed-venv/lib/python3.9/site-packages/prompt_toolkit/mouse_events.py))
Error during activate--see messages above.

xylophone21 · 2022-04-07T13:23:01Z

The downloaded gn is for x86_64 right now
file .environment/cipd/packages/pigweed/gn
.environment/cipd/packages/pigweed/gn: Mach-O 64-bit executable x86_64

The old version gn is for arm64
file .environment_bak/cipd/pigweed/gn
.environment_bak/cipd/pigweed/gn: Mach-O 64-bit executable arm64

I think that`s the reason

xylophone21 · 2022-04-08T08:12:17Z

I think I found the reason, as the below code in pigweed shows, third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/cipd_setup/wrapper.py, on M1 macos, pigweed will force download Rosetta cipd and gn.

This is change comes from google/pigweed@f1511cd, anyone can connect to google and get the reason?

# 
def platform_arch_normalized():
    platform_arch = '{}-{}'.format(platform_normalized(), arch_normalized())

    # Support `mac-arm64` through Rosetta until `mac-arm64` binaries are ready
    if platform_arch == 'mac-arm64':
        platform_arch = 'mac-amd64'

    return platform_arch

ReneJosefsen · 2022-04-08T08:19:17Z

Good catch!

xylophone21 · 2022-04-08T12:51:38Z

I revert all above rosetta code in pigweed and it works now. anyone can connect to google about that?

@andy31415 @bzbarsky-apple

diff --git a/pw_env_setup/get_pw_env_setup.sh b/pw_env_setup/get_pw_env_setup.sh
index ff74220b..b7003c5a 100755
--- a/pw_env_setup/get_pw_env_setup.sh
+++ b/pw_env_setup/get_pw_env_setup.sh
@@ -47,9 +47,9 @@ if [ "$ARCH" = "x86_64" ]; then
 fi
 
 # Support `mac-arm64` through Rosetta until `mac-arm64` binaries are ready
-if [[ "$OS" = "mac" ] && [ "$ARCH" = "arm64" ]]; then
-  ARCH="amd64"
-fi
+# if [[ "$OS" = "mac" ] && [ "$ARCH" = "arm64" ]]; then
+#   ARCH="amd64"
+# fi
 
 for HASH in $(git --git-dir="$PW_ROOT/.git" --no-pager log --max-count=10 --format=format:%H); do
   URL="https://storage.googleapis.com/pigweed-envsetup/$OS-$ARCH"
diff --git a/pw_env_setup/py/pw_env_setup/cipd_setup/update.py b/pw_env_setup/py/pw_env_setup/cipd_setup/update.py
index eb2b835b..fdfa00fb 100755
--- a/pw_env_setup/py/pw_env_setup/cipd_setup/update.py
+++ b/pw_env_setup/py/pw_env_setup/cipd_setup/update.py
@@ -137,8 +137,8 @@ def platform():
     platform_arch = '{}-{}'.format(osname, arch).lower()
 
     # Support `mac-arm64` through Rosetta until `mac-arm64` binaries are ready
-    if platform_arch == 'mac-arm64':
-        return 'mac-amd64'
+    # if platform_arch == 'mac-arm64':
+    #     return 'mac-amd64'
 
     return platform_arch
 
@@ -197,11 +197,15 @@ def write_ensure_file(package_files, ensure_file):
                    '$VerifiedPlatform mac-amd64\n'
                    '$ParanoidMode CheckPresence\n')
 
+        print("platform():", platform())
         for pkg in packages:
             # If this is a new-style package manifest platform handling must
             # be done here instead of by the cipd executable.
             if 'platforms' in pkg and platform() not in pkg['platforms']:
+                print("skip pkg:", pkg)
                 continue
+            else:
+                print("pkg:", pkg)
 
             outs.write('@Subdir {}\n'.format(pkg.get('subdir', '')))
             outs.write('{} {}\n'.format(pkg['path'], ' '.join(pkg['tags'])))
diff --git a/pw_env_setup/py/pw_env_setup/cipd_setup/wrapper.py b/pw_env_setup/py/pw_env_setup/cipd_setup/wrapper.py
index 6ca7db3c..fac4a590 100755
--- a/pw_env_setup/py/pw_env_setup/cipd_setup/wrapper.py
+++ b/pw_env_setup/py/pw_env_setup/cipd_setup/wrapper.py
@@ -137,8 +137,8 @@ def platform_arch_normalized():
     platform_arch = '{}-{}'.format(platform_normalized(), arch_normalized())
 
     # Support `mac-arm64` through Rosetta until `mac-arm64` binaries are ready
-    if platform_arch == 'mac-arm64':
-        platform_arch = 'mac-amd64'
+    # if platform_arch == 'mac-arm64':
+    #     platform_arch = 'mac-amd64'
 
     return platform_arch

andy31415 · 2022-04-08T13:12:07Z

Forwarded this to pigweed team. Tagging @keir for visibility.

mspang · 2022-04-08T17:04:03Z

We're working on it. The reason this was changed upstream in pigweed was that not all of their tools have native mac-arm64 builds yet.

In the meantime, besides reverting the bootstrap change, there are a couple of solutions (untested, I don't have an M1 device):

Set host_cpu = "arm64" manually in the args
Install and use the amd64 openssl via brew (set PKG_CONFIG_PATH) to avoid the arch mismatch with openssl at link time
Build with mbedtls (chip_crypto = "mbedtls" in the args) which avoids the openssl brew dependency altogether

mspang · 2022-04-08T17:06:45Z

@rgoliver Is there a roll that could be reverted here or would that cause other issues?

rgoliver · 2022-04-08T18:51:04Z

#16537 was the last change that updated pigweed, it was a couple weeks ago. I checked and reverting that would drop f1511cd change mentioned above, so should fix the issue. That CL provides decoding of tokenized logs for NXP, they can always roll back to build the tool in the short term so not a big issue to drop it.

The risk would be that a change went in within the past couple weeks that depended on the pigweed update, hopefully this would be caught by CI though. I did bootstrap and a couple builds locally and they all worked, so I suspect it's OK but CI would be the real test, and then watching for any other breakages on targets not covered by CI.

chadnorvell · 2022-04-09T01:00:59Z

Hey everyone, I'm on the Pigweed team and I'm the author of the change that broke things for you 🙂 I have a fix in upstream Pigweed that should solve this problem once it rolls into this repo.

To give some additional context: Pigweed didn't have official support for M1 Macs prior to google/pigweed@f1511cd, because we didn't have (and still don't have) a complete mac-arm64 toolchain available yet in CIPD, the package manager that Pigweed uses. For Pigweed projects that use the Pigweed toolchain, things didn't work on M1 Macs at all. So the temporary solution to provide experimental support on M1 Macs was to simply act like Intel Macs and use the mac-amd64 toolchain via Rosetta. This works well for teams using the Pigweed toolchains, but clearly not well if you're using the host toolchain from outside of Pigweed and external native libraries, since you'll end up with this architecture mismatch.

Now there's a bootstrap environment variable that controls whether bootstrap pulls the incomplete mac-arm64 toolchain (which is sufficient for Matter) or the complete mac-amd64 toolchain (which most Pigweed projects need to run on M1 Macs right now). Since you are not setting this variable in your bootstrap script, I expect that things will just work again once this change rolls down.

ReneJosefsen · 2022-04-09T06:25:59Z

Awesome, thanks for the detailed explanation. It sounds like we have a few ways to workaround the issue until the fix is included in the SDK, so maybe we should just close this issue for now? @bzbarsky-apple

xylophone21 · 2022-04-09T06:27:44Z

I setup a PR to fix it, but seem met another issue while bootstrap

#17229

[4/247] python3 ../../third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../../third_party/pigweed/repo/pw_unit_test --lockfile protocol_buffer/pip.lock --default-toolchain=//build/toolchain/host:mac_arm64_gcc --current-toolchain=//third_party/pigweed/repo/pw_protobuf_compiler/toolchain:protocol_buffer --capture-output -- ../../third_party/pigweed/repo/pw_protobuf_compiler/py/pw_protobuf_compiler/generate_protos.py --language python --include-file protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/includes.txt --compile-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --out-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --sources protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto
FAILED: protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python/pw_unit_test_proto/unit_test_pb2.py protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python/pw_unit_test_proto/unit_test_pb2.pyi
python3 ../../third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../../third_party/pigweed/repo/pw_unit_test --lockfile protocol_buffer/pip.lock --default-toolchain=//build/toolchain/host:mac_arm64_gcc --current-toolchain=//third_party/pigweed/repo/pw_protobuf_compiler/toolchain:protocol_buffer --capture-output -- ../../third_party/pigweed/repo/pw_protobuf_compiler/py/pw_protobuf_compiler/generate_protos.py --language python --include-file protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/includes.txt --compile-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --out-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --sources protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto
ERROR:main:Protocol buffer compilation failed!
protoc -Iprotocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --experimental_allow_proto3_optional --python_out protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --mypy_out protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto
protoc-gen-mypy: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable

xylophone21 · 2022-04-09T07:52:51Z

Hi @chadnorvell @keir above issue, is caused by the below changes in upstream Pigweed, could you please revert related code? Thanks

--- a/pw_env_setup/py/pw_env_setup/cipd_setup/pigweed.json
+++ b/pw_env_setup/py/pw_env_setup/cipd_setup/pigweed.json
@@ -63,6 +63,16 @@
         "version:2@3.17.3"
       ]
     },
+    {
+      "_comment": "Until there's an arm64 Mac version, get the amd64 Mac version on arm64 Macs.",
+      "path": "infra/3pp/tools/protoc/mac-amd64",
+      "platforms": [
+        "mac-arm64"
+      ],
+      "tags": [
+        "version:2@3.17.3"
+      ]
+    },
     {
       "path": "fuchsia/third_party/clang/${platform}",
       "platforms": [
@@ -200,4 +210,4 @@
       ]
     }
   ]
-}
+}

xylophone21 · 2022-04-11T06:06:05Z

Hi @keir with above patch, there are still many CI errors. Since I am not familiar with pigweed, could you please help to have a look at it? Thanks

#17229

chadnorvell · 2022-04-11T19:44:15Z

@xylophone21 Re: the patch you showed in this comment, I'm looking into getting a mac-arm64 build of protoc into CIPD so that this hack isn't necessary. If that can't be done today, I'll revert that change for now to unblock you.

xylophone21 · 2022-04-12T02:52:00Z

I setup a PR to fix it, but seem met another issue while bootstrap

#17229

[4/247] python3 ../../third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../../third_party/pigweed/repo/pw_unit_test --lockfile protocol_buffer/pip.lock --default-toolchain=//build/toolchain/host:mac_arm64_gcc --current-toolchain=//third_party/pigweed/repo/pw_protobuf_compiler/toolchain:protocol_buffer --capture-output -- ../../third_party/pigweed/repo/pw_protobuf_compiler/py/pw_protobuf_compiler/generate_protos.py --language python --include-file protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/includes.txt --compile-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --out-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --sources protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto FAILED: protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python/pw_unit_test_proto/unit_test_pb2.py protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python/pw_unit_test_proto/unit_test_pb2.pyi python3 ../../third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../../third_party/pigweed/repo/pw_unit_test --lockfile protocol_buffer/pip.lock --default-toolchain=//build/toolchain/host:mac_arm64_gcc --current-toolchain=//third_party/pigweed/repo/pw_protobuf_compiler/toolchain:protocol_buffer --capture-output -- ../../third_party/pigweed/repo/pw_protobuf_compiler/py/pw_protobuf_compiler/generate_protos.py --language python --include-file protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/includes.txt --compile-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --out-dir protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --sources protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto ERROR:main:Protocol buffer compilation failed! protoc -Iprotocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources --experimental_allow_proto3_optional --python_out protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python --mypy_out protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/python protocol_buffer/gen/third_party/pigweed/repo/pw_unit_test/unit_test_proto.proto_library/sources/pw_unit_test_proto/unit_test.proto protoc-gen-mypy: program not found or is not executable Please specify a program using absolute path or make sure the program is available in your PATH system variable

@chadnorvell you can ref this error log, seems next steps need protoc

chadnorvell · 2022-04-12T19:48:46Z

That change is now reverted. This should resolve the protoc issue.

xylophone21 · 2022-04-14T12:04:24Z

This issue is fixed by #17247, I think it can be closed

ReneJosefsen mentioned this issue Apr 4, 2022

CHTPTool cli does not complie on M1 Mac -> ld: symbol(s) not found for architecture x86_64 #16961

Closed

andy31415 added the darwin label Apr 5, 2022

xylophone21 mentioned this issue Apr 9, 2022

[WIP]Fix m1 build failed for Pigweed force using Rosetta #17229

Closed

chadnorvell mentioned this issue Apr 13, 2022

Build failure on M1 Mac with the error message -> No such file or directory: 'protoc' #17334

Closed

xylophone21 closed this as completed Apr 14, 2022

ReneJosefsen mentioned this issue Jun 7, 2022

Cannot compile all-clusters-app on M1 Mac #19134

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

While building out folder we are facing a issue in MAC #16759

While building out folder we are facing a issue in MAC #16759

Rajashreekalmane commented Mar 29, 2022

bzbarsky-apple commented Mar 30, 2022 •

edited

ReneJosefsen commented Apr 4, 2022

bzbarsky-apple commented Apr 5, 2022

xylophone21 commented Apr 6, 2022

ReneJosefsen commented Apr 6, 2022

xylophone21 commented Apr 6, 2022

ReneJosefsen commented Apr 6, 2022

xylophone21 commented Apr 6, 2022

xylophone21 commented Apr 7, 2022 •

edited

xylophone21 commented Apr 8, 2022 •

edited

ReneJosefsen commented Apr 8, 2022

xylophone21 commented Apr 8, 2022 •

edited

andy31415 commented Apr 8, 2022

mspang commented Apr 8, 2022 •

edited

mspang commented Apr 8, 2022

rgoliver commented Apr 8, 2022

chadnorvell commented Apr 9, 2022

ReneJosefsen commented Apr 9, 2022

xylophone21 commented Apr 9, 2022 •

edited

xylophone21 commented Apr 9, 2022 •

edited

xylophone21 commented Apr 11, 2022

chadnorvell commented Apr 11, 2022

xylophone21 commented Apr 12, 2022

chadnorvell commented Apr 12, 2022

xylophone21 commented Apr 14, 2022

While building out folder we are facing a issue in MAC #16759

While building out folder we are facing a issue in MAC #16759

Comments

Rajashreekalmane commented Mar 29, 2022

Problem

bzbarsky-apple commented Mar 30, 2022 • edited

ReneJosefsen commented Apr 4, 2022

bzbarsky-apple commented Apr 5, 2022

xylophone21 commented Apr 6, 2022

ReneJosefsen commented Apr 6, 2022

xylophone21 commented Apr 6, 2022

ReneJosefsen commented Apr 6, 2022

xylophone21 commented Apr 6, 2022

xylophone21 commented Apr 7, 2022 • edited

xylophone21 commented Apr 8, 2022 • edited

ReneJosefsen commented Apr 8, 2022

xylophone21 commented Apr 8, 2022 • edited

andy31415 commented Apr 8, 2022

mspang commented Apr 8, 2022 • edited

mspang commented Apr 8, 2022

rgoliver commented Apr 8, 2022

chadnorvell commented Apr 9, 2022

ReneJosefsen commented Apr 9, 2022

xylophone21 commented Apr 9, 2022 • edited

xylophone21 commented Apr 9, 2022 • edited

xylophone21 commented Apr 11, 2022

chadnorvell commented Apr 11, 2022

xylophone21 commented Apr 12, 2022

chadnorvell commented Apr 12, 2022

xylophone21 commented Apr 14, 2022

bzbarsky-apple commented Mar 30, 2022 •

edited

xylophone21 commented Apr 7, 2022 •

edited

xylophone21 commented Apr 8, 2022 •

edited

xylophone21 commented Apr 8, 2022 •

edited

mspang commented Apr 8, 2022 •

edited

xylophone21 commented Apr 9, 2022 •

edited

xylophone21 commented Apr 9, 2022 •

edited