Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v4.4.2] [Build] _Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit"); (IDFGH-8479) #9938

Closed
chipweinberger opened this issue Oct 8, 2022 · 8 comments
Assignees
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@chipweinberger
Copy link
Contributor

chipweinberger commented Oct 8, 2022

IDF version.

v4.4.2-378-g9269a536ac

Operating System used.

macOS

How did you build your project?

Command line with idf.py

What is the expected behavior?

I'm using 4.4.2, top of branch, stock, it should build.

What is the actual behavior?

I should have brought up this issue a year ago.

On v4.3.x, v4.4.x, I've always had to comment out these 3 lines in esp_app_format.h because of a build error.

_Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit");
_Static_assert(sizeof(esp_image_header_t) == 24, "binary image header should be 24 bytes");
_Static_assert(sizeof(esp_app_desc_t) == 256, "esp_app_desc_t should be 256 bytes");

I've never taken the time to figure out what causes it.

Steps to reproduce.

No special steps. Building with idf.py.

Build or installation Logs.

Log:

/Volumes/User/MBP-Google-Drive/jamcorder/firmware/esp-idf/components/bootloader_support/include/esp_app_format.h:24:15: error: expected constructor, destructor, or type conversion before '(' token
 _Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit");
               ^
/Volumes/User/MBP-Google-Drive/jamcorder/firmware/esp-idf/components/bootloader_support/include/esp_app_format.h:91:15: error: expected constructor, destructor, or type conversion before '(' token
 _Static_assert(sizeof(esp_image_header_t) == 24, "binary image header should be 24 bytes");
               ^
/Volumes/User/MBP-Google-Drive/jamcorder/firmware/esp-idf/components/bootloader_support/include/esp_app_format.h:124:15: error: expected constructor, destructor, or type conversion before '(' token
 _Static_assert(sizeof(esp_app_desc_t) == 256, "esp_app_desc_t should be 256 bytes");
               ^
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
@chipweinberger chipweinberger added the Type: Bug bugs in IDF label Oct 8, 2022
@github-actions github-actions bot changed the title [v4.4.2] [Build] _Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit"); [v4.4.2] [Build] _Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit"); (IDFGH-8479) Oct 8, 2022
@espressif-bot espressif-bot added the Status: Opened Issue is new label Oct 8, 2022
@kayzen9
Copy link

kayzen9 commented Oct 9, 2022

@chipweinberger

Missing CPP guards in following header (?)

_Static_assert(sizeof(esp_chip_id_t) == 2, "esp_chip_id_t should be 16 bit");

For C++, it should be static_assert

@chipweinberger
Copy link
Contributor Author

My code is all CPP, so that's a good theory.

Yes the capitalization is a bit weird.

@igrr
Copy link
Member

igrr commented Oct 10, 2022

Thanks for raising this issue, indeed the static asserts should be in an #ifndef __cplusplus block. Several other IDF header files seem to have the same issue.

(_Static_assert is correct syntax for C code until C23 standard; static_assert is correct for C++ and C>=23)

@espressif-bot espressif-bot added Status: Selected for Development Issue is selected for development and removed Status: Opened Issue is new labels Oct 12, 2022
@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Selected for Development Issue is selected for development labels Nov 9, 2022
@chipweinberger
Copy link
Contributor Author

chipweinberger commented Nov 19, 2022

Bumping. This is still broken on v4.4 branch (maybe master too)?

I'd open a PR, but I think I should get my other PR's in first, hah 🙂

@o-marshmallow
Copy link
Collaborator

o-marshmallow commented Nov 21, 2022

Hi @chipweinberger ,

An internal PR is on-going to fix this issue, it will be backported to v4.4 as soon as it is merged

@chipweinberger
Copy link
Contributor Author

appreciate the update! :)

@espressif-bot espressif-bot added Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: In Progress Work is in progress Resolution: NA Issue resolution is unavailable labels Nov 22, 2022
@lamaanrana-eaton
Copy link

I am using IDF v4.4.0, also tried V4.4.5 but I am getting this error while building the code. I am not sure what to do here or how to get around it. it is only happening with one repo. I can compile all the projects from the examples in the ESP-IDF

@0xjakob
Copy link
Collaborator

0xjakob commented Mar 5, 2024

I am using IDF v4.4.0, also tried V4.4.5 but I am getting this error while building the code. I am not sure what to do here or how to get around it. it is only happening with one repo. I can compile all the projects from the examples in the ESP-IDF

@lamaanrana-eaton Do you have a minimal reproducing example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

7 participants