Ohayo!
Budując na linuxie pluginowy runtime Kaiju natrafiłem na problem. Statyczna biblioteka runtime'owa potrafi ładować, odładować i wywołać funkcjonalność pluginowej biblioteki .so.
Problem jest z poprawnym zbudowaniem biblioteki .so:
gdy kompiluję .so z opcją -fPIC, to gcc karze mi skompilować z flagą -fPIC także libKaijuRuntime.a (której funkcjonalności to .so używa) - czy w takim razie muszę wszelkie libki używane przez .so przekompilować z flagą -fPIC?
Jeśli już przekompiluję libKaijuRuntime.a z flagą -fPIC, to kompilacja .so przechodzi,
Budując na linuxie pluginowy runtime Kaiju natrafiłem na problem. Statyczna biblioteka runtime'owa potrafi ładować, odładować i wywołać funkcjonalność pluginowej biblioteki .so.
Problem jest z poprawnym zbudowaniem biblioteki .so:
gdy kompiluję .so z opcją -fPIC, to gcc karze mi skompilować z flagą -fPIC także libKaijuRuntime.a (której funkcjonalności to .so używa) - czy w takim razie muszę wszelkie libki używane przez .so przekompilować z flagą -fPIC?
Jeśli już przekompiluję libKaijuRuntime.a z flagą -fPIC, to kompilacja .so przechodzi,
Właśnie uzupełniam bibliotekę standardową, a w ramach poprawek doszło między innymi komunikacja pomiędzy aplikacją Kaiju, a biblioteką załadowaną przez kod, a na dodatek działa już w shellu (chwilowo tylko linux, ale lada dzień i winda)! ^^
Jeśli miałbym jakoś określić Kaiju, to nazwałbym go JSem w wersji
very very very strict, i właśnie dlategoźródło: comment_ceow0yoUkFEIqeDhlAq2wpvnBNoIDhDo.jpg
PobierzZamiast
var c = Program:Add (Program:a, Program:b)
Było
var c = Add (a, b)
Ad. 1. żadnego GC - obiekty zarządzane w IntuicioVM są smart pointerami, czyli pamięć jest deallokowana wtedy, gdy już nie ma żadnej referencji na obiekt. Czyli nie potrzeba będzie nic więcej ponad to, co już jest (tak, tak. to wszystko już działa out-of-the-box) :3
Ad. 2. da, dyrektywa
injectwstrzykuje kod assemblera maszyny wirtualnej. po stronie VMki nie istnieje żadna zahardcode'owana klasa. Wszystko da się rozszerzać i zmieniać wedle