Including opencv native libraries as resources in enso runner binary

[JaroslavTulach]

Pull Request Description

test/Image_Tests can now be executed in native image mode of enso runner. All that's needed is to include (the right) native_libraries present in opencv-4.7.0-0.jar as resources in the native image binary. This is another step in the #10121 quest.

Important Notes

• originally (with 60269cd) the size of bin/enso executable went up too much - e.g. from ~200MB to 441MB
• the size bloat was caused by the same problem as Wasting 100MB by Standard.Image: Implement polyglot/lib #11483
• we don't want to fix native binaries for all the platforms when building executable for a single OS and architecture
• by selecting just the right lib we go down to 265MB
• given the libopencv.so has ~65MB itself, it seems natural the binary grew by such amount
• of course with Wasting 100MB by Standard.Image: Implement polyglot/lib #11483 we would do even better: the bin/enso executable would stay ~200MB and it would load the 65MB libopencv.so from lib/Standard/Base/polyglot/lib/linux/amd64/libopencv.so

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  TypeScript,
  Rust
  style guides.
• Unit tests have been written where possible.

[JaroslavTulach]

These are the libraries we care about when it comes to packaging Standard.Image for native image executable:

enso.$ unzip -l built-distribution/enso-engine-*/enso-*/lib/Standard/Image/0.0.0-dev/polyglot/java/opencv-4.7.0-0.jar | grep -v class$  | cut -c31- | grep -v /$ | grep ^nu | grep -v README
nu/pattern/opencv/linux/ARMv7/libopencv_java470.so
nu/pattern/opencv/linux/ARMv8/libopencv_java470.so
nu/pattern/opencv/linux/x86_64/libopencv_java470.so
nu/pattern/opencv/osx/ARMv8/libopencv_java470.dylib
nu/pattern/opencv/osx/x86_64/libopencv_java470.dylib
nu/pattern/opencv/windows/x86_32/opencv_java470.dll
nu/pattern/opencv/windows/x86_64/opencv_java470.dll

when we select just the binary for the right platform (like 3b826f0 does), we go down from 441MB to 265MB on Linux.

[hubertp]

Doesn't this render enso a bit useless? >400MB for an exec seems like a lot. If we really want to go this way then we really need to prioritize #11483. Maybe this should be done the other way around?

[JaroslavTulach]

Doesn't this render enso a bit useless? >400MB for an exec seems like a lot.

There has been some progress already:

when we select just the binary for the right platform (like 3b826f0 does), we go down from 441MB to 265MB on Linux.

It is hard to go lower (with the resource based approach) when the libopencv.so has 65MB and Enso itself has ~200MB.

If we really want to go this way then we really need to prioritize #11483. Maybe this should be done the other way around?

On Friday @jdunkerley sounded like wanting the quickest solution without waiting for any classloading changes, build system changes, etc. that are associated with #11483.

[jdunkerley]

On Friday @jdunkerley sounded like wanting the quickest solution without waiting for any classloading changes, build system changes, etc. that are associated with #11483.

Happy for us to build the better approach for this if not hideous to do so.