Error mismatched types
lorenzo-pirchio opened this issue · 18 comments
When I build the esp-idf-template for esp-idf 5.1 with Esp-idf 5.1, I get this error:
error[E0308]: mismatched types
--> C:\Users\lpirc.cargo\registry\src\index.crates.io-6f17d22bba15001f\esp-idf-sys-0.33.7\src\lib.rs:50:62
|
50 | const ESP_IDF_TIME64_CHECK: ::std::os::espidf::raw::time_t = 0 as crate::time_t;
| ^^^^^^^^^^^^^^^^^^ expected i32, found i64
error[E0308]: mismatched types
--> C:\Users\lpirc.cargo\registry\src\index.crates.io-6f17d22bba15001f\esp-idf-sys-0.33.7\src\lib.rs:52:51
|
52 | const ESP_IDF_TIME64_CHECK_LIBC: ::libc::time_t = 0 as crate::time_t;
| ^^^^^^^^^^^^^^^^^^ expected i32, found i64
Can anyone help me? Or does anyone have a suggestion?
against what target are you compiling? what compiler version are you using? rust libc itself has a fix for esp-idf v5 to use correct time_t as a i64, and that is activated with the rustflags that are specified inside the .cargo/config.toml. So if that is not working it can only be two things i think. Either you are using an relative old rustc compiler that uses a older rustc libc that doesn't include the esp-idf v5 fix, or you have something in your environment that messes things up.
The target is "xtensa-esp32s3-espidf", the compiler is rustc 1.79.0.
What are the rustflags that need to be added in config.toml?
The templates default add the correct one if you are choosing esp-idf 5 and its present otherwise the type would not be correctly i64. But the compiler things its should be i32 - and that's make it strange because it should be i64 for idf5
I think the problem may be because I'm working with the xmpp crate on esp-idf-template, so I need to replace all the dependencies to libc to the newest version. Do you think it may be a possible solution?
Ahh, so your binary also currently depends on libc like 0.2.155 or something? I can see that then there could be a simple version mismatch in your dependancy graph. In esp-idf-sys we are using the libc bindings to run this time_t version check but nothing else.
You can verify that with running cargo tree | grep libc If you see different versions than that is the core problem. You can try to add a [patch.crates-io] section for libc so everything in your graph is using the patched libc version than the problem should go away.
I can try to add the patch section and see what will happen
If one of your dependancys also pins an old libc version as a hard dependancy that can be a problem. You would have to upgrade that crate to a newer libc version. So as i said best is to check cargo tree
I checked cargo tree and all the crates depend to libc 0.2.155. There aren't crates using older versions, but I still have the error
That is a wild stretch here, you are on windows right? i know they had a couple of problems compiling the new xtensa 1.79.0 and 1.78.0 for the windows platform. That's why both xtensa compiler versions are still pre-release. Do you also happen to have the 1.77 version installed?
Yes, I'm using windows. I can download the 1.77 version now and try it.
In any case, if that turns out fruitless, in your shoes i would try to create a minimal reproducible setup, and have a look if some of your create dependancys use time_t in any particular manner and may have a definition based on a 32bit platform here and are ignoring our upstream esp-idf libc code that defines time_t as 64bit. Other than that if one crate doesn't get build correctly with the rustflags = [ "--cfg", "espidf_time64"] propagated so the compiler doesn't build with the correct time_t size is the only other option i see.
I tried to put 1.77 as default toolchain but I still have errors, I can't compile even the basic template.
Could it be a problem that I use CC=C:\MinGW\bin\gcc.exe instead of xtensa-esp32s3-elf-gcc.exe?
I'm using esp-idf 5.1.4 and the template is for 5.1.3, should I change the template using the master ?But it doesn't work
I'm working with 4.4 template on espidf 5.1.4 and I don't get that error but others related to the crate I'm using
Yeah user provided env variables overriding stuff can cause a problem here, that's what i was getting at when first talked about "or you have something in your environment that messes things up."
Could you clarify something for me: on CC, should I use GCC for Windows or xtensa-esp32s3-elf-gcc.exe?
you cant use any other compiler/linker than the one provided for each esp variant. We install them automatically via embuild so usually people dont need to fiddle with anything in that respect.
Should I use this C:.embuild\espressif\tools\xtensa-esp32s3-elf\esp-12.2.0_20230208\xtensa-esp32s3-elf\bin\xtensa-esp32s3-elf-gcc or xtensa-esp32s3-elf-cc?
The gcc versions are tied to the ESP-iDF versions, for example esp-idf 5.1 is using gcc12 while ESP-iDF 5.2 is using gcc13. So you need to be real careful here and cant just do stuff willy nilly.
So again if you are not sure what you are doing i think you should start researching more on that front upfront. And i emphasize again under normal circumstances you don't need to fiddle around here at all, it should be all handled by the buildsystem automatically. If something is not handled by the buildsystem than we need to tackle it there, not my randomly changing stuff in the ENV.
I encourage people to play around and i don't want to give the impression that you should not try to learn to understand how things work underneath, but i think that can be simpler archived by reading the sourcecode in all the different layers of the buildsystem in the rust and C part. and see what we are actually doing.
Closing this as its not really an error on our site, if you have more questions feel free to join the matrix chat.