Which libraries are needed

[saschaarthur]

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: https://github.com/NativeScript/nativescript-dev-webpack/issues/1026 (security wise)

[saschaarthur]

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]

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]

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]

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]

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]

Those binaries are generated as part of the standard V8 build process which is described here: https://github.com/NativeScript/android-v8

[NathanaelA]

@darind - Isn't Snapshots depreciated and going away in NS7?

[darind]

@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]

@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]

@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]

OK so from what you are saying :

• it cannot be turned off ? What does that mean. Means it is always on or does it means once it is turned on there is no turning it off?
• we agree that to enable it you just have to set the prop in the package.json? I have it enabled in 3 apps for quite some time. Did not see any issue either in dev or prod.

I will try and run some tests in cold boot time with code cache and with/without snapshot

Thanks for the explanations

[darind]

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]

@darind, What technique are you using on the iOS version to avoid the expired cache on update; maybe we can apply that to the Android runtime...

Lots of corner cases I can think of; so curious what methods your using to invalidate the cache...

[darind]

@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]

@darind -

How much of this do we control; does the TimeStamp of the JS file occur when extracted or from the APK/IPK build dates embedded in them? Are the cache file date/time synced to the original JS file?

I can see this scenario:

• v1.0 app JS File 1/1/2020
• App Installed 2/10/2020
• Cache File 2/10/2020
• I release Update v1.1 - 2/09/2020 -- Sits in Apples Queue until 2/11/2020
• Client get v1.1, JS: 2/09/2020

JS files are dated 2/9, but cache file is 2/10...

Some interesting questions... :D

[darind]

@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.