I had assumed that the executable created by dart2native was machine code.
It appears what is actually happening is that it is bytecode, and said bytecode
is concatenated with the Dart interpreter to create the final result.
This explains why the executable is destroyed when you strip it: what really
happens is the bytecode is just removed from the executable leaving only the
interpreter.
I am not sure if creating machine code is even possible with the Dart project,
so this issue can serve as a place for someone to clarify one way or the other.
Dart code is compiled to native code by the AOT compiler. This executable code is just not necessarily packaged in a platform specific executable format (e.g. ELF on Linux, Mach-O on Mac or PE on Windows). Instead we pack it into, what we call a _snapshot_ which later can be loaded by the runtime system. Format of that snapshot is an implementation detail which should be irrelevant to the end user.
@mraleph yeah, thats bytecode, not machine code, as it requires the Dart interpreter or Dart virtual machine to accompany the snapshot.
Its not the same thing as machine code, and shouldnt be marketed as such. Calling it AOT is a misnomer I would say.
@cup the AOT snapshot contains _actual_ machine code which is directly executed by the CPU. This code was produced ahead of time (AOT) from your Dart source. There is no translation or interpretation. There is just a loading/linking step, which is similar to a step that OS does for you when you load a native executable format.
You are confusing several different things - executable format (ELF, etc) and format in which your Dart code is stored (eg machine code vs bytecode vs source).
@cup
Whatever you call it, its not the same thing as what you get with C, C++ or Go.
This is nonsense and not neccessary. Dart is not a system programming language.
Having a single executable binary is all we need so far.