-
Notifications
You must be signed in to change notification settings - Fork 97
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
Upgrade to WebKitGTK 2.36.3 #169
Conversation
- Keeps only Intl variant - Upgrade NDK to r23 - Set minimal Android SDK to 21 - Remove unused patch - Update CI
"cmake;3.18.1" \ | ||
"ndk;23.2.8568313" | ||
# move out builtin icu headers from ndk and prevent icu build errors | ||
mv "${ANDROID_HOME}/ndk/23.2.8568313/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/unicode" "${ANDROID_HOME}/ndk/23.2.8568313/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/unicode2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this necessary, can you clarify what was the error? Does it mean that building jsc will not work locally? And if it works locally, then it should be possible to make it work on ci without this patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from NDK r22, the icu headers are builtin inside NDK. when building icu, the includes such as #include "unicode/utypes.h"
will access to NDK headers first and lead to build errors.
i also need to move out the unicode/
folder from NDK when building locally.
@@ -19,7 +19,7 @@ $PLATFORM_CFLAGS \ | |||
CMAKE_LD_FLAGS=" \ | |||
-latomic \ | |||
-lm \ | |||
-lc++_shared \ | |||
-static-libstdc++ \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why static?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
upgrade NDK to 23.2.8568313. we need newer versions because the newer webkit needs std::filesystem that doesn't support on NDK r21. also, because the NDK r23 libc++_shared.so has std::filesystem symbols that older version doesn't have. to prevent developers use pickFirst to pick wrong libc++_shared.so, i turned to use link static c++ runtime instead.
left it on pr description. feel free to let me know if that's not clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not sound like a safe change. e.g. if we have jsc with statically linked stl and e.g. expo-gl or react-native build with shared stl then we are including stl twice and potentially different versions of it
https://developer.android.com/ndk/guides/cpp-support#sr
In this situation, the STL, including and global data and static constructors, will be present in both libraries. The runtime behavior of this application is undefined, and in practice crashes are very common. Other possible issues include:
Memory allocated in one library, and freed in the other, causing memory leakage or heap corruption.
Exceptions raised in libfoo.so going uncaught in libbar.so, causing your app to crash.
Buffering of std::cout not working properly.
I just wanted to mention my concern on that, I have only a minimal idea of how all this works, so if you think it's a safe change I'm fine with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting! i would say thankfully the libjsc.so is really independency. the exceptions, memory allocations are not across other libraries. the JSCRuntime.cpp implementation in react-native only relies on C interfaces, so it might be safer in this case.
otherwise, TBH i don't have a better solution toward the inconsistent libc++_shared.so issues.
I have test jsc-android@294992.0.0 on react native 0.69.4 but failed to start the error log is:
if i use 250230 as default, it works, the log is:
|
hi @aweffr, do you mind to create a github repository of minimal reproducible example for me? i tested jsc-android@294992.0.0 + react-native@0.69.4 on android 12 emulator and it works for me. |
Hi @Kudo, Is there any way that I can use non Intl for this JSC version? Enabling Intl significantly increases the app bundle size though |
@khoanguyen-yang unfortunately no. as the pr described the new jsc has no flag to turn off Intl now. |
@Kudo do we need to update the RN template and remove the non-intl flavor there? |
@cortinico as facebook/react-native#35504 (comment) mentioned, we don't have to update RN template in the mean time. |
# Why fixes #178 # How - manually pick necessary changes for ndk r23 from #169. it's ndk r23c which is newer than react-native 0.71's r23b. i cannot build jsc on top on r23b successfully. hopefully r23b <-> r23c is good for abi safety. - fix build errors for webkitgtk 2.26.1 + ndk r23. - unlike #169, this pr is still using shared c++ runtime. - update test project to 0.71 and build from source code because we need a patch to link libunwind in libjscexecutor.so. # Test Plan ci passed
The same issue. Did you find the solution ? |
@Hesowcharov jsc-android@294992.0.0 is not compatible with older react-native since android ndk is incompatible. |
@Kudo Thank you for your reply! So, after rn 0.69 (i used 0.69.12) it's recommended to use the default jsc (from facebook) ? I'm just wondering that it should be working since the example app (in this repo) works with rn 0.69 🤔 |
for someone who will try to migrate to RN 0.69-0.70, move straight to 0.71.x (my version is 0.71.15) => there jsc-android@294992.0.0 works!
|
Why
upgrade to latest WebKitGTK 2.36.3 (svn r294992). mostly from community requests and hopefully to fix the crashes on samsung android 12 devices.
How
size changes:
Test Plan