You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[V8] getsectdatafromheader_64 is deprecated in macOS 13.0 #45
Builds on macOS 13.0 will fail since getsectdatafromheader_64 is deprecated as of 13.0, replaced by getsectiondata(). This is in V8's codebase as opposed to workerd, so it may just be worth noting in the README (or not, since 13.0 is still in beta).
external/v8/src/base/platform/platform-darwin.cc:56:22: error: 'getsectdatafromheader_64' is deprecated: first deprecated in macOS 13.0 [-Werror,-Wdeprecated-declarations]
char* code_ptr = getsectdatafromheader_64(
^~~~~~~~~~~~~~~~~~~~~~~~
use getsectiondata()
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach-o/getsect.h:130:14: note: 'getsectdatafromheader_64' has been explicitly marked deprecated here
extern char *getsectdatafromheader_64(
^
1 error generated.
Target //src/workerd/server:workerd failed to build
System information
System Version: macOS 13.0 (22A5352e)
Kernel Version: Darwin 22.1.0
Hmm, we should figure out how to build V8 with warnings not treated as errors, otherwise we're going to be persistently running into problems like this where something was deprecated but V8 hasn't handled it yet.
Or maybe we should blanket disable warnings when compiling dependencies... it's not like we're going to go fix their warnings.
Disabling them makes sense but I'd still like to be able to bring them back optionally. Can we turn them off by default and have an option to show them? They often give us a good heads up on upcoming changes.
@jasnell To be clear I think we still want warnings when our own code uses deprecated V8 APIs. What we don't want is warnings when V8 internal code uses deprecated APIs from its own dependencies.
Disabling them makes sense but I'd still like to be able to bring them back optionally. Can we turn them off by default and have an option to show them? They often give us a good heads up on upcoming changes.
how can i disable them, i can't turn it off, this makes me feel confused.
Activity
kentonv commentedon Sep 28, 2022
Hmm, we should figure out how to build V8 with warnings not treated as errors, otherwise we're going to be persistently running into problems like this where something was deprecated but V8 hasn't handled it yet.
Or maybe we should blanket disable warnings when compiling dependencies... it's not like we're going to go fix their warnings.
jasnell commentedon Sep 29, 2022
Disabling them makes sense but I'd still like to be able to bring them back optionally. Can we turn them off by default and have an option to show them? They often give us a good heads up on upcoming changes.
kentonv commentedon Sep 29, 2022
@jasnell To be clear I think we still want warnings when our own code uses deprecated V8 APIs. What we don't want is warnings when V8 internal code uses deprecated APIs from its own dependencies.
dio commentedon Oct 27, 2022
@KianNH I can successfully compile on Ventura (macOS 13) by using: https://github.com/cloudflare/workerd/compare/main...dio:workerd:allow-catalina-ventura.patch?full_index=1 (basically to achieve this: #45 (comment)). Not sure if this is the right way here (by introducing another v8 patch).
Also, do you have a plan allowing people to install this via homebrew? I can try to set up the formula if it is desirable (it has releases).
Thank you!
caass commentedon Nov 8, 2022
Just bumping to say this now breaks building
workerdon the latest XcodeETA workaround:
bazel clean --expungeinworkerddirectorybazel buildshould work nowdio commentedon Nov 8, 2022
Or you can apply the patch here: https://github.com/cloudflare/workerd/compare/main...dio:workerd:allow-catalina-ventura.patch?full_index=1
lgyhit commentedon Dec 23, 2022
how to use this patch?
lgyhit commentedon Dec 23, 2022
how can i disable them, i can't turn it off, this makes me feel confused.
kentonv commentedon Dec 23, 2022
@lgyhit Nice patch, if you send a pull request I'll merge it.
mrbbot commentedon Jan 16, 2023
Hey @dio! Would you be interested in submitting a PR containing your patch?
dio commentedon Jan 17, 2023
@mrbbot I have submitted it here: #276.
fix(server): facet channel UaF after alarm timeout
fix(server): facet channel UaF after alarm timeout
Enforce a declared expectedLength's underflow on consumption
Enforce a declared expectedLength's underflow on consumption