Fix: time_t is 64 bits on Emscripten

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.

[hoodmane]

Since July 8, 2022:
emscripten-core/emscripten#17401https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/alltypes.h?plain=1#L83

Fixes#3306

[rustbot]

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]

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]

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.

[hoodmane]

@sbc100 does this look correct to you?

[sbc100]

That looks right to me yes.

[alex]

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

[sbc100]

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

[JohnTitor]

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]

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

[JohnTitor]

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

[kleisauke]

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]

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]

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.

[tgross35]

I think this can be closed since IIUC #3962 makes this change. Please reopen if this isn't correct.