`firefly compile` fails during linking due to undefined reference to `init:boot/1` about firefly HOT 3 CLOSED

Thank you for sharing the current project status and the plan 🙂 It was really helpful to me to understand what I can do now.

Currently, Erlang modules must export an init:boot/1 symbol that defines the entry point for executables.

I see. So, I edited the init.erl file to rename start/0 function to boot/1. And it worked!

--- a/native_implemented/otp/tests/internal/lib/erlang/display_1/with_atom/init.erl
+++ b/native_implemented/otp/tests/internal/lib/erlang/display_1/with_atom/init.erl
@@ -1,6 +1,6 @@
 -module(init).
--export([start/0]).
+-export([boot/1]).
 -import(erlang, [display/1]).
 
-start() ->
+boot(_) ->
   display(atom).

$ ./bin/firefly compile native_implemented/otp/tests/internal/lib/erlang/display_1/with_atom/init.erl
   Compiling native_implemented/otp/tests/internal/lib/erlang/display_1/with_atom/init.erl
    Compiled init
      Linker generated executable to ... /_build/firefly/x86_64-unknown-linux-gnu/init
    Finished built init in 1s
​
$ file ./_build/firefly/x86_64-unknown-linux-gnu/init
./_build/firefly/x86_64-unknown-linux-gnu/init: ELF 64-bit LSB pie executable, 
x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=5ea7145898756dc05bdcf6de3fcf2a40affc1e84, 
for GNU/Linux 3.2.0, with debug_info, not stripped
​
$ ./_build/firefly/x86_64-unknown-linux-gnu/init
atom

I also realized that the CI job x86_64-unknown-linux-gnu-compiler is running cargo make test-lit regularly, and its test files in tests/lit directory are up to date.

NOTE: The runtime is quite limited at the moment while I finalize the design for the GC and scheduler integrations, so you should expect that many basic things are missing.

I will be playing around with Firefly a bit more but I will try not to bother you until your work is done. Thank you for your hard work!

from firefly.

I'm glad you were able to get the sample program running! Always good to have someone else reproduce a successful build :)

I expect to have some updates soon that will open up the scope of what is possible quite a bit, but feel free to ask any questions you have in the meantime!

from firefly.

Currently, Erlang modules must export an init:boot/1 symbol that defines the entry point for executables. I'm currently working on a set of changes that ships a builtin init and treats Erlang sources more like erlc does, but this is just a side effect of building things up incrementally.

NOTE: The runtime is quite limited at the moment while I finalize the design for the GC and scheduler integrations, so you should expect that many basic things are missing. While you can compile pretty much any Erlang sources, linking will likely fail due to missing symbols as there is no standard library being built right now, it is truly bare bones Erlang. That won't be the case much longer, but just want to give you some context for your experimentation 😃

from firefly.