Repository navigation
Which libraries are needed #5298
Description
Could you please tell us more about this project?
- The Readme is a one liner ..
- Just a lot of binarys here, no source(?)
- not even sure which librarys we need for those dynamic linked stuff
We currently running on build issues:
/tmp/snapshot-tools/mksnapshot-tools/v8-v8.0.426.16/linux-x64/mksnapshot-arm: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
and its almost impossible to find the right libgcc_s.so.1...
Somehow also related to: NativeScript/nativescript-dev-webpack#1026 (security wise)
Activity
saschaarthur commentedon Apr 14, 2020
libx32gcc-8-dev is needed
It seems the tools are build with different tool chains / versions?
Still want to see the source & the build procedure for this somewhere..
darind commentedon Apr 14, 2020
Normally those binaries are intended to be used inside a docker image that the NativeScript CLI will run on the host machine to ensure that all required dependencies are met.
Which version of the CLI are you using?
saschaarthur commentedon Apr 14, 2020
root@e97c9a4b38ae:~/mobile# tns --version
6.4.1
Also it seems to run on the host not inside of the docker container, by adding libx32gcc-8-dev to the host the issue was solved..
darind commentedon Apr 14, 2020
ok, so you are running this on a Linux host - in this case it won’t use a container which is an issue.
Concerning the dependencies, mksnapshot-arm is a 32 bit process and requires that the Linux host has 32 bit mode enabled in order to be able to run such processes. Unfortunately the most recent distributions no longer have it enabled by default and thus the need for an isolated container even for Linux hosts.
I will transfer this issue to the NativeScript CLI repository as it is more relevant there.
saschaarthur commentedon Apr 14, 2020
sure makes sense.
Could you try to provide some more transparency what this tools are used for and how we could build them our self (from source)?
darind commentedon Apr 14, 2020
Those binaries are generated as part of the standard V8 build process which is described here: https://github.com/NativeScript/android-v8
NathanaelA commentedon Apr 14, 2020
darind commentedon Apr 14, 2020
@NathanaelA, our tests have shown that code cache performs at least as good as snapshots if not better, so snapshots can be deprecated. The complexity they introduce can be avoided with code cache.
farfromrefug commentedon Apr 14, 2020
@darind you are saying that today code cache set to true now is as good as snapshot and that we are better off not using snapshot and enable code cache ? Won't it change cold boot time ? This would make crazy faster builds!
darind commentedon Apr 14, 2020
@farfromrefug, in our tests code cache was even faster than snapshot. Yes, cold boot might be impacted a little but that’s a fair price to pay for getting faster startup times on subsequent starts.
That’s the reason why code cache is the only available option in the v8 ios runtime and we made it so that it cannot be turned off :-)
This being said, there are still some stuff that needs to be verified/tested before recommending this in the Android runtime. Some timestamp based expiration must be implemented so that updates of the javascripts from the PlayStore would invalidate this cache and the other thing is to disable it in Debug builds as it might severely impact development (changes made to scripts not being applied and all kind of other weird cases)
farfromrefug commentedon Apr 14, 2020
OK so from what you are saying :
I will try and run some tests in cold boot time with code cache and with/without snapshot
Thanks for the explanations
darind commentedon Apr 14, 2020
It means that in the v8 based iOS runtime code cache is always on when building in release mode and always off in debug mode.
And for the Android runtime your users may hit some nasty edge cases during app updates if you ship your app with enabled code cache to the PlayStore.
NathanaelA commentedon Apr 14, 2020
darind commentedon Apr 14, 2020
@NathanaelA, in iOS we compare the timestamp of the cache file with the timestamp of the corresponding javascript file. And if the javascript file is newer than the cache then obviously this file has been modified and we invalidate the cache file.
And in debug mode we do not use code cache at all because of the frequent changes.
Of course this same approach can be applied in android.
NathanaelA commentedon Apr 14, 2020
darind commentedon Apr 14, 2020
@NathanaelA, in our tests, at least on an iOS device, the timestamp occurs when the file is modified at its present location on the device, which works fine for the cache expiration check.
But for Android those are perfectly valid questions that need to be verified and tested before making code cache the default option in release builds.
[-]Which librarys needed[/-][+]Which libraries are needed[/+]