Wrapping minetesetserver in FreePascal

[Tomas Brod]

Hello <people>!

So I was trying to wrap the server executable to freepascal program. The program was not supposed to do much. Just print hello world and call main from minetest. A basic experiment before adding hooks and api glue everywhere.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

{$L minetestserver.o} {L as link in an object file}
procedure main(argc:integer; argv:ppchar); cdecl; external name 'main';
BEGIN
 write('Hello, world'#10);
 main(argc,argv)
END.


Note: I am not really asking for help. I am just reporting my experimentation results.

The minetestserver.o was produced by adding -r to CMake linker flags. The first issues were related to duplicate symbols main and _start (both in c and pascal runtime), i solved that by removing crt0 from link and renaming main to cmain. This produce an executable, but it crashed in dynamic linker initialization.

As have no knowledge in dynamic linking I decided to link statically. So I linked all minetest object files to my minetestserver.o, which repeatedly produced tons of unresolved symbols until I added -lc -lm -lgcc_s -lz -lsqlite3 -lluajit-5.1 -lrt -lpthread -ldl -lcurl -lstdc++ and gmp and jsoncpp libraries to the link(age). Then a last error about dso_handle was solved by few lines in linker script.
This again produced useless executable which told me it was not found, despite being clearly present and rwx in the directory. (gdb was able to open the file and read symbols, but failed on 'r' commnd with NoSuchFileOrDir)

Why I was trying to do that? I tought about kind of binary modding interface.
I like about FPC that you just USES your units and they get pulled in with all their dependencies recompiled as needed, and it does that real fast. The minetest.o file could be distributed as binary and on server startup mods will get linked linked in. Saving mod developer from editing (c)Makefiles and user from resolving dependencies.

Next time I will probably try it the other way, with dl_open. Will keep you updated :)

Ps: do not relate my lack of knowledge in dynamic linking with the rest of compiler toolchain. I was able to assemble an glue and link a barebone OS.

[Sokomine]

Pascal...that has been a long time ago by now. It used to be Turbo Pascal when I last worked with it. Like most languages, it lived through the libraries it came with. FreePascal didn't have those libraries, so using other languages became more convenient. And that might be a problem here as well. We do have the lua api the engine provides, and we have other mods which sometimes act as libraries. Another modding language will still depend on what the engine offers.

Will keep you updated :)

Please do so! While it might not be very useful as such, it's still very intresting as to how this might be accomplished.

[benrob0329]

I'm learning FP, it's a very nice language. It would be good for mods that need native speed (E.G. mobs), and since it compiles faster than a cheetah on steroids (see what I did there? (FPC joke)) , the code would be able to be compiled on demand, and scripted in Lua.

[Tomas Brod]

I was trying to understand src/script structure. At first I thought what a scary code, but now I see a lot of logic there. But the cpp_api is a lie, better name would be callbacks.

Done some experiments with dl_open and added a hello-world lua api function. Most mods will remain in Lua. I am thinking of minetest.loadoject to load and optionally compile a plug-in. Plug-ins can export functions to lua and hook callbacks to core directly. Allowing plug-ins to start new therads could solve some lag issues.

But the biggest lag source is when lua-mapgen-mod does on_generated. Despite the callback being run from EmergeTherad, the lua interpteter is locked so nothing can hapen in ServerTherad. Not even chest-to-inventory.

It would be good for mods that need native speed (E.G. mobs), and since it compiles faster than a cheetah on steroids (see what I did there? (FPC joke)) , the code would be able to be compiled on demand, and scripted in Lua.

It is faster, but not that fast "54701 lines compiled, 3.7 sec", lcl-based applications compile even slower.
I do not fully understant the CAO and SAO (mobs), so support for theese may come late or not at all.

[Tomas Brod]

Did not touch the minetest source yet. Learned how to use libdl in C. Learned how to convert pascal o+ppu to shared library (was suprised the libld does not like plain .o files): use ppumove, it converts one or more units into shared lib and modifies the ppu(s) to use it.

FPC stores unit information in ppu files (similar to header and makefile). I written a test program to read ppu and print dependencies, wether it requires initialization or finalization. Also names of static shared and smart binaries and names of source files (with last modified date).

There is a System unit, it is like libc. All units implicitly uses system. The system unit includes memory manager, which can be overriden to not conflict with mm of libc, the same is true with thread manager.

I plan to support both C and Pascal, do you konw any other compiled language that might fit?

[Tomas Brod]

Pascal...that has been a long time ago by now. It used to be Turbo Pascal when I last worked with it. Like most languages, it lived through the libraries it came with. FreePascal didn't have those libraries, so using other languages became more convenient.

There is Turbo C, too. FPC includes Dos and Crt units, which work even on linux and the compiler is backwards compatible. Unfortunately most code from the turbo era access hardware directly. Pascal is not better or worse than C. They are just different, like german and french (Schmeterling :).