compatibility for older macs in wast-parser.c

[i3roly]

hi,

so i have seen that a new wasm2c was pushed to mozilla-unified/central the other day.

i noticed that the new tokenqueue class is using a member (value):
https://github.com/WebAssembly/wabt/blob/main/src/wast-parser.cc#L3824

that is not available for older mac targets.

 3:12.54 /Users/Gagan/Downloads/mozilla-unified/third_party/wasm2c/src/wast-parser.cc:3749:43: error: 'value' is unavailable: introduced in macOS 10.13 unknown
 3:12.54  3749 |   return tokens[i ^ static_cast<bool>(n)].value();
 3:12.54       |                                           ^
 3:12.54 /Users/Gagan/.mozbuild/MacOSX14.4.sdk/usr/include/c++/v1/optional:1057:33: note: 'value' has been explicitly marked unavailable here
 3:12.55  1057 |     constexpr value_type const& value() const&
 3:12.55       |                                 ^
 3:12.55 1 error generated.

is it possible the developers would consider adding/modifying the structure so that it will work on macs older than 10.13?

thanks

[sbc100]

So this variant of optional::value() is not part of the libc++ dylink that shipped in 10.13? How old is 10.13 now? Is supporting that version a hard requirement for you?

I guess there are a couple of options:

1. Use some kind of polyfill / replacement / alternative?
2. Statically link libc++ to avoid the issue

[i3roly]

as i understand it, this is a bug in APPUL's SDK, not an inherent issue from older platforms:

https://stackoverflow.com/questions/44217316/how-do-i-use-stdoptional-in-c

i think it's a little unfair to ditch older targets on the basis of "how old is xx now" when the issue isn't the platform per-se, but APPUL's abuse of its developer community, which seems to keep coming back for more.

it feels like an APPUL bug because it says "macOS 10.13 unknown" which doesn't feel like the typical SDK error.

even if i change

  return *tokens[i ^ static_cast<bool>(n)].value();

to

  return *tokens[i ^ static_cast<bool>(n)];

i now get a weird:

 0:28.62 Undefined symbols for architecture x86_64:
 0:28.62   "_wasm_rt_grow_memory", referenced from:
 0:28.62       _w2c_rlbox_sbrk_0 in rlbox.wasm.o
 0:28.62       _w2c_rlbox_dlmalloc in rlbox.wasm.o
 0:29.18 ld: symbol(s) not found for architecture x86_64
 0:29.28 clang++: error: linker command failed with exit code 1 (use -v to see invocation)
 0:29.29 gmake[4]: *** [/Users/Gagan/Downloads/mozilla-unified/config/rules.mk:544: ../../../dist/bin/XUL] Error 1
 0:29.29 gmake[3]: *** [/Users/Gagan/Downloads/mozilla-unified/config/recurse.mk:72: toolkit/library/build/target] Error 2

doesn't seem like a related error. @shravanrn any ideas?

[sbc100]

I don't know that this is an apple's SDK bug so much as an incompatibility with the version of libc++ that apple shipped with macOS 10.13, no?

I assume that what the libc++ headers as saying that if they allowed this method then the resulting binary would not load on 10.13 due to dylib compatibility issues?

Also, I'm not sure I understand what you are trying to say with unfair to ditch older targets on the basis of "how old is xx now". Are you saying it should be based instead of how many folks use the older target? If so I would agree with that. How many do still use 10.13?

[sbc100]

I guess one thing we should do is define which is the oldest version of macOS that wabt build can target and then we should be passing -mmacosx-version-min=XXX to the compiler to keep us honest.

[sbc100]

It looks like that way we would do that is to add CMAKE_OSX_DEPLOYMENT_TARGET to our cmake.

[i3roly]

no, i'm not building on 10.13. i am building on 10.14 or 10.15, but this isn't the point.

i am using the mmacosx-verison-min already, and this is how the issue cropped up.

as i understand that stackoverflow, this is an APPUL SDK issue. the person who had 27 upvotes on the stackoverflow seems to do a good job of arguing APPUL deviating from the standard.

in any case i'm okay with using the * operator to get around it, and i doubt that this change is the reason i'm now experiencing build failures in firefox central that i didn't experience before.

[sbc100]

IIUC correctly the problem is that std::bad_optional_access is missing from the libc++.dylink in 10.13. This means that when you target 10.13 the compiler will correctly warn if you try to use APIs that depend on std::bad_optional_accessat runtime (i.e.std::optional::value()`).

Was apple wrong to ship 10.13 without std::bad_optional_access? Maybe? Most likely LLVM simply had not implemented it yet at the time when 10.13 shipped.

Basically, if we want to target 10.13 then we need to limit ourselves libc++ library feature that were available at that time when 10.13 was shipped since libc++.dylink is baked into the OS.

If we do decide we want to support running wabt on 10.13 then we should add CMAKE_OSX_DEPLOYMENT_TARGET=10.13 to our cmake file.

Currently, the status quo is that wabt doesn't support running on 10.13. Do you (or some of your users maybe?) need to run wabt on 10.13? If not, can you bump your macosx-verison-min?

[SoniEx2]

do you need native wabt? wabt can be compiled to webassembly, this is used by projects such as e.g. chicory and it works great.

[i3roly]

Do you need to limit yourselves or is it possible to have a MACOSX_VERSION_MIN <= 1013 cpp macro that would use the * operator‎ instead of the value() member? You could then add a line in the readme that this macro is unsafe, unsupported and is being provided for the sake of compatibility? Sent from my BlackBerry 10 smartphone on the Rogers network. From: Sam CleggSent: Friday, 10 January 2025 12:28 PMTo: WebAssembly/wabtReply To: WebAssembly/wabtCc: gagan sidhu; AuthorSubject: Re: [WebAssembly/wabt] compatibility for older macs in wast-parser.c (Issue #2527) IIUC correctly the problem is that std::bad_optional_access is missing from the libc++.dylink in 10.13. This means that when you target 10.13 the compiler will correctly warn if you try to use APIs that depend on std::bad_optional_accessat runtime (i.e.std::optional::value()`). Was apple wrong to ship 10.13 without std::bad_optional_access? Maybe? Most likely LLVM simply had not implemented it yet at the time when 10.13 shipped. Basically, if we want to target 10.13 then we need to limit ourselves libc++ library feature that were available at that time when 10.13 was shipped since libc++.dylink is baked into the OS. If we do decide we want to support running wabt on 10.13 then we should add CMAKE_OSX_DEPLOYMENT_TARGET=10.13 to our cmake file. Currently, the status quo is that wabt doesn't support running on 10.13. Do you (or some of your users maybe?) need to run wabt on 10.13? If not, can you bump your macosx-verison-min? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#2527 (comment)", "url": "#2527 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[sbc100]

Do you need to limit yourselves or is it possible to have a MACOSX_VERSION_MIN <= 1013 cpp macro that would use the * operator‎ instead of the value() member? You could then add a line in the readme that this macro is unsafe, unsupported and is being provided for the sake of compatibility?

That sounds like a possibility yes. However I think that the * operator has different semantics to the value() method, so it might not be simple drop in replacement. But I think we can find a workaround yes.

Perhaps as a followup to #2528 we can reduce CMAKE_OSX_DEPLOYMENT_TARGET to 10.13 and apply a workaround?

[i3roly]

it's up to you on how you want to tackle it @sbc100 but i wanted to mention that it seems this * operator hasn't caused anything bad in my testing, which was simply running firefox 136 on a 10.8 VM and going to nytimes to see if video played with sound, which it did.

i dunno if that * operator is so bad. i don't want you bending over backwards. that stackoverflow said the only drawback is the lack of an access check. however it does seem like you know more about STD, standards, etc than i, and as such i'll leave it up to you.

re compiling with firefox:
@SoniEx2 thanks for chiming in, it turns out my issue with compilation was an artefact of using the following commit:

https://hg.mozilla.org/mozilla-unified/rev/607266cea485dde9ac0393378974c99f814c65ca

which migrates rlsoundbox back to XUL as opposed to lgpllibs, which allows the use firefox's shared locks for older targets that don't have c++17.

by adding this diff:
https://hg.mozilla.org/mozilla-unified/diff/38ef245d937c619df0ca620d38d20bd96a4217cd/security/rlbox/rlbox.mozbuild#l1.12

to this file:
https://hg.mozilla.org/mozilla-unified/diff/607266cea485dde9ac0393378974c99f814c65ca/security/rlbox/moz.build#l1.30

the build compiles without issue, and seems to work fine.

sorry about that @shravanrn i'll issue an apology in the upcoming commit

[sbc100]

@i3roly if you would like to send a PR to lower CMAKE_OSX_DEPLOYMENT_TARGET to 10.13 and avoid using value() I think that would be reasonable.

However I would want to know that you have a real use case for running wabt on 10.13 yourself, otherwise I don't think it is worth it. Note that running wabt on 10.13 is not the same thing has building the output of wasmc with 10.13 support (which is what firefox does I believe).

[sbc100]

Note that the difference between operator* and value() seems to be that the latter will throw in the value is missing but with the former its simply undefined behaviour.