-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
BREAKING - Upgrade to upstream newlib 4.0.0 release #7708
Conversation
Includes 64 bit time_t and 5 years of updates. Binary incompatible with libraries which use time_t (due to the size difference). Recompiling with the new newlib should be sufficient for most libraries, assuming source is available.
Note that this requires a new toolchain (since GCC includes newlib), so be sure to run |
Upgrade to Newlib 4.0.0 tag. The toolchain should be rebuilt before any merge as it still contains a copy of newlib 3.3.0. Only 1 incompatibility seen with internal TZ structures requiring a minor patch to the core.
This comment has been minimized.
This comment has been minimized.
The CI caching doesn't pick up updated toolchain releases, so for now dieable it until get.py becomes a little smarter and allows for removing MD5-mismatched files.
Somewhere along the line the copy of libc in tools/sdl/libc was taken out of the build process. Files in there are not used, take add'l time to build and install on a toolchain release, and just cause confusion. Remove them.
Quiet impressed. With your latest commits Tasmota does compile successfull and it does start!! |
@Jason2866 one thing to be aware of, maybe related to the NTP stuff: If you've got a binary struct saved somewhere (say, with last time updated), the size of that struct will now change and you'll probably be interpreting garbage at that point (4->8 byte time_t).
LittleFS timestamp handling now working w/64-bit times. FAT should already be safe until 2107 per Wackypedia. |
The core was setting 64-bit times automatically on new file creation or updates, but would fail when attempting to read them back due to 64/32b confusion. Now attempt to read 64b time, and if that fails fallback to reading 32b time to allow both old and new FS to preserve timestamps.
@jjsuwa-sys3175 contributed three additional optimization .MD patches for GCC 10.2, as well as a slightly faster pgm_read_byte() macro. Rebuild the toolchain using these new changes.
.github/workflows/pull-request.yml
Outdated
uses: actions/cache@v2 | ||
with: | ||
path: ./tools/dist | ||
key: key-linux-toolchain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc, changing 'key' will force it to use a different cache
it will be expired at some point, but it is not as clear as something like travis (rip)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx. I think generally we're OK and the un-done patch here was just a stopgap during development.
The original commenting-out was because the releases have a datestamp in them which ends up making all builds in a day conflict. So get.py would find gcc-20121101.tgz(from 9AM) in the cached dir and not try and d/l the newer one gcc-20121101.tgz(from 11AM). The cached version's MD5 would mismatch, so the build failed w/o a toolchain. Easy fix, drop the caching. W/everything coming from GH.com, anyway, the cache probably doesn't make much difference...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, speeds on github are really good, so cache most of the time takes longer than just fetching the sources directly...
I think it also could be this 'template', making key depend on the .json so it is always new whenever toolchain is modified
key: ${{ runner.os }}-${{ hashFiles('package/package_esp8266com_index.template.json') }}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an awesome idea! Right now the cache will grow w/obsolete versions of the tools, but one based on the JSON would fix that problem.
Did you want the PR for this? OTW I can throw it together quickly.
…lash * upstream/master: (72 commits) Typo error in ESP8266WiFiGeneric.h (esp8266#7797) lwip2: use pvPortXalloc/vPortFree and "-free -fipa-pta" (esp8266#7793) Use smarter cache key, cache Arduino IDE (esp8266#7791) Update to SdFat 2.0.2, speed SD access (esp8266#7779) BREAKING - Upgrade to upstream newlib 4.0.0 release (esp8266#7708) mock: +hexdump() from debug.cpp (esp8266#7789) more lwIP physical interfaces (esp8266#6680) Rationalize File timestamp callback (esp8266#7785) Update to LittleFS v2.3 (esp8266#7787) WiFiServerSecure: Cache SSL sessions (esp8266#7774) platform.txt: instruct GCC to perform more aggressive optimization (esp8266#7770) LEAmDNS fixes (esp8266#7786) Move uzlib to master branch (esp8266#7782) Update to latest uzlib upstream (esp8266#7776) EspSoftwareSerial bug fix release 6.10.1: preciseDelay() could delay() for extremely long time, if period duration was exceeded on entry. (esp8266#7771) Fixed OOM double count in umm_realloc. (esp8266#7768) Added missing check for failure on umm_push_heap calls in Esp.cpp (esp8266#7767) Fix: cannot build after esp8266#7060 on Win64 (esp8266#7754) Add the missing 'rename' method wrapper in SD library. (esp8266#7766) i2s: adds i2s_rxtxdrive_begin(enableRx, enableTx, driveRxClocks, driveTxClocks) (esp8266#7748) ...
Includes 64 bit time_t and 5 years of updates.
Binary incompatible with libraries which use time_t (due to the size
difference). Recompiling with the new newlib should be sufficient for
most libraries, assuming source is available.