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

Fix: time_t is 64 bits on Emscripten #3569

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

@rustbot
Copy link
Collaborator

rustbot commented Jan 30, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@alex
Copy link
Member

alex commented Jan 30, 2024

At risk of asking a dumb question, how does this work with respect to backwards compatibility? What happens if one uses this patched libc with an older emscripten?

@alex
Copy link
Member

alex commented Jan 30, 2024

To answer my own question: I think you probably need to put a branch in build.rs (search for emcc_version_code in there) and emit a cfg and make this conditional on emcc version.

But obviously I defer to the libc maintainers.

Comment on lines 20 to 28
// time_t was type:
//
// - long from v1.5.4 (2013/08/08) until v3.1.11
// - int from v3.1.11 (2022/05/20) until v3.1.16
// - _Int64 from v3.1.16 (2022/07/14)
//
// And it's still int64 today. The change from long to int was marked as a
// nonfunctional change since wasm64 was considered to be not working yet in
// v3.1.11. So it suffices to say it's 32 bit until v3.1.16 and 64 bit after.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbc100 does this look correct to you?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks right to me yes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Hey Sam, long time! Hope you're doing well!)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What! Hi. What a pleasure to see your name pop up in my inbox. I hope you are doing well too.

@JohnTitor
Copy link
Member

For libc v0.3, I think it's fine to bump up the minimum supported emscripten version to reduce our complexity. The release date mentioned in OP seems enough to bump to me.

@hoodmane
Copy link
Author

Is there an explicit minimum supported version somewhere? I don't find it.

@JohnTitor
Copy link
Member

No, we could define it on v0.3 if you like.

@kleisauke
Copy link
Contributor

FWIW, Rust currently specifies Emscripten 2.0.5 as the minimum version it supports, see:
rust-lang/rust#107221 (comment)

Bumping that to version 3.1.16 would probably be fine.

@JohnTitor
Copy link
Member

Is there any policy around the supported version of Emscripten on rustc? Maybe it's good time to ask to bump on rustc as well.

@benjamin-sieffert
Copy link

Is there any policy around the supported version of Emscripten on rustc? Maybe it's good time to ask to bump on rustc as well.

Honestly, with the amount of breaking ABI changes emscripten development is doing to their libc, they can’t really ask for anyone to support a wide range of versions.

Of course, the reason they are so liberally doing those changes is because, practically speaking, C programs are statically linked against emscripten libc: It all goes into a single wasm bundle. There is normally no risk that an emscripten program ends up running against an older (or newer) version of emscripten’s libc.

On the flipside, this means there are no real reasons for anyone to be on older versions of emscripten. There is even an emscripten-equivalent to rustup so that developers aren’t tied to the version that their distribution has packaged. https://github.com/emscripten-core/emsdk

The attemps that were made to support different emcc versions in this repo lead to convoluted structure (not covered by automatic testing, either) and don’t even work without -Zbuild-std, right? Even then I think they are bugged, as some std::fs operations are broken for me after #3282.

Imho under these considerations it would be very reasonable for Rust to only ever support one "quite recent" version of emscripten and no others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants