ESP8266 Community Forum

- Sat May 06, 2023 9:44 pm #96358

To begin with, the int != int32_t has been a known issue for a long time. The Espressif header files really suck, all types are wrong. I think with newer GCC's the default warning/error levels have changed and you're into that, because I have been getting this for ages already. The only solution (and I do this) is to maintain your own versions of the header files. The only drawback is that in theory a definition might change at some time and you'd need to change your own version. But I haven't seen this for a very long time. Also the original header files are overflowing with #define statements which is both ugly and wrong, these should be either enums or static consts, in same rare cases an inline function.

As for lwip I can really recommend to compile your own version anyway. That way you can tweak all sorts of options which can make it use far less memory than default. Not everybody needs e.g. 16 sockets and ip defragmentation (not tcp segmentation). You get also the opportunity to make lwip run in a piece of pre-allocated memory (which can come from a static variable instead of malloc()), which makes the amount of used memory much more predictable, very little chance of suddenly running out of memory.

Yeah I have ANSIfied the headers in the NonOS SDK and have stripped almost everything out of c_types.h and instead add the stdbool, stdint, etc, headers.

The real reason I am trying to compile the latest toolchain is to try and move to the RTOS and some common code between ESP8266 and ESP32 chips. But I need to be able to get my existing code to work first.

The super annoying thing about the whole change to 32bit integers in the latest toolchains is that you need to replace all your *printf formatting, but if you use the supposedly agnostic PRIxxx macros, they break on the earlier toolchains because the definitions inside GCC itself rely on the size of long not int

- Sat May 06, 2023 10:01 pm #96359

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

Haven't seen that (yet).

I think this started in newlib 3.x - they moved some of the low level system functions into libgloss, and there's a version of this for non OS usage, called libnosys. Basically stubs out thread and reentrant functions as they aren't needed in a single threaded environment. This is one description:

3.1. The relationship between libgloss and newlib

Newlib is now divided into two parts. The main newlib directory contains the bulk of the code for the two main libraries, libc and libm, together with any architecture specific code for particular targets.

The libgloss directory contains code specific to particular platforms on which the library will be used, generally referred to as the Board Support Package (BSP). Any particular target architecture may have multiple BSPs, for example for different hardware platforms, for a simulator etc.

The target architecture specific code within the newlib directory may be very modest - possibly as little as an implementation of setjmp and a specification of the IEEE floating point format to use.

The board support package is more complex. It requires an implementation of eighteen system calls and the definition of one global data structure, although the implementation of some of those system calls may be completely trivial.

Bit more progress but still not close:
- 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

What do you exacly mean with the "nano versions"? Aren't you using newlib?

Yes - again newlib 3.x onwards has a newlib-nano version available which is even smaller, and crosstool for the ESP chips builds this, as well as versions of the libraries with no RTTI, and for working round the PSRAM bugs in the ESP32 chips. You apparently switch usage of these by adding a spec file command to the compiler but I can't see that it's working

- __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 remember having this issue as well, I had my implementation of ctype for this, but now it doesn't seem to be required anymore. Maybe it's indeed the lwip stuff.

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

That's interesting? What did you do exactly, the sprintf formatting specifiers have been the same for a very long time. You may want to workaround it by not changing the formatting specifiers and casting the ints to a "well-known" type like int or unsigned int. Or just change the error into a warning.

See my last post - I previously used %x, %d, %u in my code, but the new toolchain now needs these to be %lx, etc. The other option is to use the PRIx32 macro throughout, but when I did this I found the old toolchain breaks because the PRI macros are defined based on the size of long and not size of int! Which is bizarre

- Sun May 07, 2023 3:12 am #96362 I really don't like using Espressif stuff for several reasons:
- for several years they have been focusing on the combo of ESP32 and the RTOS SDK. I don't trust them with ESP8266 NONOS SDK.
- the quality of coding of Espressif is horrible. I have spent quite some time correcting issues or potential issues due to lame coding.
- they tend to make changes in open source projects without having a real need for it, which makes it harder to update the project to it's current state (git master).
- all sorts of constructs using Python, which imho, are not really necessary

What they should do instead is supply patches to the upstream gcc, newlib and crosstool-NG projects and then everybody can use them without any extra work. But that's not in their own interest, apparently.

- Sun May 07, 2023 3:21 am #96363

The libgcov thing I was able to fix (typedef unsigned long long int intptr_t), but now I have an error I really don't know how to fix:

Code: Select all/home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/gcc/../include/ansidecl.h:40:1: error: expected initializer before 'extern'


There is really nothing wrong with this code:

Code: Select all#ifndef _ANSIDECL_H
#define _ANSIDECL_H 1

#ifdef __cplusplus
extern "C" {
#endif

Fixed it!

It was the result of a missing semicolon in the other fix. With the semicolon in place it still didn't work, had to start another 10 or so runs to get it working, but now I nailed it. Apparently this header file would need to include <stdint.h> but it's not available at the time of compilation (for intptr_t). So I typedef'ed it so various standard types (including things like the - always available - __intptr_t) but all didn't work for various reasons. Finally I resorted to changing the three occurrences of intptr_t to "long long int" (which is equally sized = 8 bytes) and then it worked.

I just finished a full compilation run of my code, had to locally exclude one error/warning because gcc has become more strict and then it went ok. IRAM usage has remained the same, DRAM use has dropped a little and FLASH use increased a bit (but that's ok, we have plenty of that). Now I still need to flash it and check.

If you're using ESP's with at least 2 Mbyte of flash, you might consider using my low-on-Espressif building framework It gives flexible OTA (without using any Espressif stuff) and only a single image needs to be compiled for all slots (all addresses in flash are equal, thanks to RBOOT in "big" mode).