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

BREAKING - Upgrade to upstream newlib 4.0.0 release #7708

Merged
merged 20 commits into from
Dec 23, 2020

Conversation

earlephilhower
Copy link
Collaborator

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.

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.
@earlephilhower earlephilhower changed the title Upgrade to upstream newlib 3.3.0 release BREAKING - Upgrade to upstream newlib 3.3.0 release Nov 14, 2020
@earlephilhower
Copy link
Collaborator Author

Note that this requires a new toolchain (since GCC includes newlib), so be sure to run get.py if you want to try it out.

@d-a-v d-a-v added the alpha included in alpha release label Nov 17, 2020
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.
@earlephilhower earlephilhower changed the title BREAKING - Upgrade to upstream newlib 3.3.0 release BREAKING - Upgrade to upstream newlib 4.0.0 release Nov 18, 2020
@earlephilhower

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.
@Jason2866
Copy link
Contributor

Quiet impressed. With your latest commits Tasmota does compile successfull and it does start!!
After some time sync problems it gets NTP time and is up already for 10 minutes.

@earlephilhower
Copy link
Collaborator Author

earlephilhower commented Dec 3, 2020

@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).

This reminds me that I need to update the LittleFS time_t attribute.

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.
uses: actions/cache@v2
with:
path: ./tools/dist
key: key-linux-toolchain
Copy link
Collaborator

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)

Copy link
Collaborator Author

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...

Copy link
Collaborator

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') }}

via https://github.com/actions/cache#creating-a-cache-key

Copy link
Collaborator Author

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.

@earlephilhower earlephilhower merged commit 9de8373 into esp8266:master Dec 23, 2020
@earlephilhower earlephilhower deleted the newlib330 branch December 23, 2020 19:21
davisonja added a commit to davisonja/Arduino that referenced this pull request Dec 28, 2020
…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)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alpha included in alpha release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants