Unable to cross-compile for 32 bit arm

[stlevkov]

Problem

The project was successfully compiled for bridge and chip-tool using this commit:
commit [c2be9bc]

• No compilation errors

But after switching to a new:
commit [e92157a]

• Error compiling

• expected behavior
  No errors during compilation

• actual behavior
  error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘size_t’ {aka ‘unsigned int’

• system configuration
  Architecture: armv7l Cortex-A8

Log:
`../../third_party/connectedhomeip/src/platform/Linux/DeviceInfoProviderImpl.cpp:62:68: note: format string is defined here

62 | ChipLogProgress(DeviceLayer, "Get the fixed label with index:%ld at endpoint:%d", mIndex, mEndpoint);`

Proposed Solution

use "%zd", instead of %ld, for site_t of mIndex argument

[stlevkov]

Hi,
Cannot be reproduce with recent commits. Tested with [a8d12af]

[vindicatorr]

@stlevkov, I'm experiencing this issue as well.

connectedhomeip/config/esp32/third_party/connectedhomeip/src/app/util/mock/attribute-storage.cpp:281:35: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'int' [-Werror=format=]
[build]   281 |     ChipLogDetail(DataManagement, "Reading Mock Endpoint %" PRIx32 "Mock Cluster %" PRIx32 ", Field %" PRIx32 " is dirty",
[build]       |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build]   282 |                   aPath.mEndpointId, aPath.mClusterId, aPath.mAttributeId);
[build]       |                   ~~~~~~~~~~~~~~~~~
[build]       |                         |
[build]       |                         int

I tried looking at the build logs that you were passing, but I wasn't seeing which toolchains were being used.
I was looking for -esp-elf-g++ in the workflow build logs, and wasn't finding anything. I guess the details are hidden from the ninja output.

I thought I'd make fixes myself and issue my first-ever PR, but after following the "Contributing Guidelines", and running the Builds workflow (manually since I missed out on enabling it prior to subsmission), my PR changes failed the workflow check.

I then came across this lengthy thread espressif/esp-idf#9511 which refers to https://docs.espressif.com/projects/esp-idf/en/release-v5.0/esp32/migration-guides/release-5.x/gcc.html#int32-t-and-uint32-t-for-xtensa-compiler.
Note how the fix looks to only be for xtensa, and riscv was already correct. So I'd guess if your commits were passing, that they were only being built for xtensa, and not riscv, and/or not using the latest esp-idf?
I always try to build the latest of everything when I can.

I'll admit I built my own toolchain for my RISC-V esp32-c3, but for due-diligence, I went ahead and downloaded their release of riscv32-esp-elf-gcc11_2_0-esp-2022r1-linux-amd64.tar.xz from https://github.com/espressif/crosstool-NG/releases, and that too failed.
My toolchain build was done in November, theirs was July.

EDIT0: Odd, while walking through the definitions starting with aPath.mEndpointId, it looks like EndpointId is supposed to be uint16_t, not int as the warning says.
src/app/util/mock/attribute-storage.cpp:274 - CHIP_ERROR ReadSingleMockClusterData
-> src/app/ConcreteAttributePath.h:34 - struct ConcreteAttributePath : public ConcreteClusterPath
-> src/app/ConcreteClusterPath.h:48 - EndpointId mEndpointId
-> src/lib/core/DataModelTypes.h:37 - typedef uint16_t EndpointId
-> /riscv32-esp-elf/riscv32-esp-elf/sys-include/sys/_stdint.h:36 - typedef __uint16_t uint16_t
-> /riscv32-esp-elf/riscv32-esp-elf/sys-include/machine/_default_types.h:57 - typedef __UINT16_TYPE__ __uint16_t
Just to be sure of my sanity, using a simple esp-only app (non-Matter), I did a sizeof for uint16,32, and int, and got the expected 2,4,4.

EDIT1: And for my first PR ever that I was going to submit: https://github.com/vindicatorr/connectedhomeip/commit/edf0287a885a1fb8ab9ca7c3066fd5698be5d6f3

EDIT2: Welp, I pulled the connectedhomeip/chip-build-esp32:latest, set things up the way I normally do (manually, I avoid the scripts for "reasons"), built Matter's temperature example, and it was successful.
I then copied my project, and that built successfully as well.
So now I need to find the disconnect between what's in the docker image, and my system.
I copied over my clone of connectedhomeip, and the latest riscv toolchain release, but I quickly found out that the docker image uses an older esp-idf, so I couldn't use the latest toolchain.
So 2 clear differences is the toolchain and the esp-idf versions. Next I'll be making those the latest and see if that causes the failure.
I'm "thinking" it may be the toolchain. I just encountered a different issue accidentally when working through this one, and "mistakenly"(?) submitted an issue for that (at esp-idf, because it was with the hello-world example).
It just smells like it could be toolchain-ishy.

EDIT3: Ugh, I guess there's incompatibilties between esp-idf and compiler versions. For example, static asserts no longer requiring a "message" component, or std=gnu++20 not being built-in or something.
So my options will be to stick with the older esp-idf and compiler, or continue with my fork and make "fixes"(?) myself.