I’ve got a small command-line program on Debian Testing (using Haxe 4.0.0-rc.3, and HashLink 1.9.0) that I’m able to build and run fine via HL/JIT, but I’d like for comparison to build and run it via HL/C.
My program is just in a src/Main.hx file.
My hlc.hxml file looks like:
-p src
-D hl_ver=1.9.0
-m Main
--hl out/main.c
When I build with that I get:
$ haxe hlc.hxml
Code generated in out/main.c automatic native compilation not yet implemented
Then when I subsequently try to compile that C output using gcc:
gcc -O3 -o myapp -std=c11 -I out out/main.c -Lhl
I get an enormous number of error lines (filling up my terminal window buffer), a tiny snippet of which looks like:
{snip}
/tmp/cc4xfmSb.s:26919: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26921: Error: junk `(%rip)' after expression
/tmp/cc4xfmSb.s:26921: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26923: Error: junk `(%rip)' after expression
/tmp/cc4xfmSb.s:26923: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26925: Error: junk `(%rip)' after expression
/tmp/cc4xfmSb.s:26925: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26927: Error: junk `(%rip)' after expression
/tmp/cc4xfmSb.s:26927: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26929: Error: junk `(%rip)' after expression
/tmp/cc4xfmSb.s:26929: Error: operand type mismatch for `lea'
/tmp/cc4xfmSb.s:26963: Error: operand type mismatch for `call'
I’ve also tried
gcc -O3 -o myapp -std=c11 -I out out/main.c -Lhl /usr/local/lib/libhl.so
That doesn’t look like errors you’d get from a missing compiler option but an invalid generated assembly.
Hashlink 1.10.0 was released, you might want to try with it, maybe it fixes your issue.
Otherwise you should open a bug report on Issues · HaxeFoundation/hashlink · GitHub.
which gcc version do you use? I had similar issues when using gcc-9, but with gcc-8 it did compile.
With actual HL and Haxe the problem is gone for me.
Ok, Nicolas pointed out in the bug report that there was a specific issue with rc.3 and HL/C on GNU/Linux. I switched back to rc.2 and ran the gcc command again, getting a large number of errors like this:
$ gcc -O3 -o myapp -std=c11 -I out out/main.c -Lhl
/usr/bin/ld: /tmp/cclUg4Uh.o: in function `Date_new':
main.c:(.text+0xfe6): undefined reference to `hl_date_new'
/usr/bin/ld: /tmp/cclUg4Uh.o: in function `StringBuf_new':
main.c:(.text+0x1002): undefined reference to `hl_alloc_bytes'
/usr/bin/ld: /tmp/cclUg4Uh.o: in function `hl__Bytes_Bytes_Impl(short, bool __restrict)':
main.c:(.text+0x1025): undefined reference to `hl_alloc_bytes'
/usr/bin/ld: main.c:(.text+0x103b): undefined reference to `hl_bytes_blit'
/usr/bin/ld: /tmp/cclUg4Uh.o: in function `StringBuf_add':
main.c:(.text+0x1070): undefined reference to `hl_value_to_string'
/usr/bin/ld: main.c:(.text+0x109e): undefined reference to `hl_alloc_bytes'
/usr/bin/ld: main.c:(.text+0x10b5): undefined reference to `hl_bytes_blit'
/usr/bin/ld: main.c:(.text+0x10d0): undefined reference to `hl_bytes_blit'
{snip}
You might need -lhl instead of -Lhl.
The first one mean to link against libhl.so, which contains the functions it’s currently complaining about.
While the second one means to add the ./hl directory to the link path, and since you don’t have any link (-lname) that don’t have a lot of effect.
