ESP8266 Community Forum

- Wed Apr 26, 2023 3:38 am #96290 So everything is compiling and it's very fast - especially as it's built under Cygwin, which is a lot slower - but I'm getting a lot more compilation errors flagged.

Some of these are actually really good and are less than perfect code that I've written, but one error has me wondering. It's flagging errors in my sprintf routines of the form:

Code: Select allerror: format '%d' expects argument of type 'int', but argument 2 has type 'int32_t' {aka 'long int'} [-Werror=format=]

error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]


This compiled fine before, and so now I'm not sure whether the old compiler was missing the error, or the new compiler is not quite right.

ints should be 32 bit, so a format string of %d, %u, %x etc should expect a 32 bit integer, but this seems to indicate that int != int32_t, which it's calling a 'long int'. One thing that is different is that newlib has been built with C99 I/O format support - could this be it?

Any ideas appreciated

Last edited by davydnorris on Tue May 02, 2023 8:49 pm, edited 1 time in total.

- Wed Apr 26, 2023 6:44 pm #96295 OK so after much googling I think I've found my answer - it's actually working as designed and is also a problem in the ESP32 IDF as well

https://github.com/espressif/esp-idf/issues/9511

It's noted in the IDF 5.0 migration guide as well so, if you're going to use the new toolchain based on my mods, this will be something you'll need to take into consideration

https://docs.espressif.com/projects/esp-idf/en/v5.0.1/esp32/migration-guides/release-5.x/gcc.html#int32-t-and-uint32-t-for-xtensa-compiler

- Fri Apr 28, 2023 12:33 am #96299 So I've made a lot of progress, but with a few hiccups along the way...
- everything compiles, but I had to go through my code and change the print formatting to take into account the issue found in the previous post
- everything runs under the latest python except gen_appbin.py. I tried to convert it to Python 3 but it's a piece of crap. I fixed the function changes, and the indentation problems (any programming language that relies on whitespace as part of its grammar is a joke) but the checksum calculations seem to treat binary data as ASCII and vice versa to the point where I gave up and forced it to run under python2
- everything linked fine and produced a binary, but then I realised the SDK has its own copies of libc and libgcc
- when I linked against the new versions of libc and libgcc my code was way oversize. Linking to the libc_nano was better but still not good
- there were references to missing functions __getreent, pthread_setcancelstate, __ctype_ptr__, _exit, _getpid_r, _kill_r, _fclose_r and _fflush_r. These seem to indicate I'm missing a flag to turn off use of re-entrant versions of functions somewhere. I'll need to investigate that

- Tue May 02, 2023 9:43 pm #96319 Bit more progress but still not close:

- found that almost all the missing functions have been moved out into libgloss or libnosys, so you need to add nosys to your list of libs

- still trying to get --specs=nonsys.specs to work properly. Does anybody know how it should be used? I thought you just added it to the link line and it automatically added -lnonsys and the nano versions of the libraries but it seems to not do anything

- __ctype_ptr__ error is actually caused by liblwip being compiled with an old GCC version so I'll have to make or find a newer version of that

- I now get an undefined reference to 'end' when linking libnosys

- I'm still double the size of iram

I used to compile with irom versions of the libraries, so I tried to flip my build back to my old working toolchain to compare sizes and now all the sprintf formatting changes I made make it not compile . So I think I'll need to go back through my code and use the C99 PRIxxx format specifiers to make it platform independent