Hi List

This is my first post to the list and I'm new to fpc too.

I'm interested in using fpc to create .so/.dll for the Neko virtual machine (http://www.nekovm.org), instead of using C for the same task. So that means translating header files. I've done some of this and had some success but I'm getting some random problems occurring.

Neko uses the boehm garbage collector, so my question is, does fpc play well with boehm? My assumption has been that fpc could be used as a straight replacement for C.

Thanks for any wisdom.

bd

Op Sun, 26 Aug 2007, schreef blackdog:

I'm not aware of any uses in practice, but I expect it will work. FPC's memory manager is repleacable by means of procvars, so you have a lot of flexibility.

Daniël

Someone recently posted on this list that he tried to get it to work with FPC, but didn't manage to do so.

Jonas

Hi Daniël

Thanks for the quick reply. I don't necessarily want fpc to interact with boehm directly by redirecting the memory manager calls, however now that you've mentioned it could be a solution, my question is should an fpc .so be a direct replacement for a C .so? Can you think of any reason when that would not be the case - apart from bad translation of header files. For example, neko uses dlopen with RTLD_LAZY to load the .so, does fpc expect RTLD_NOW or anything like that?

Thanks again

bd

Op Sun, 26 Aug 2007, schreef blackdog:

An FPC .so can be a perfect replacement for a C .so. I'm not aware of limitations.

Can you think of any reason when that would not be the case - apart from bad translation of header files. For example, neko uses dlopen with RTLD_LAZY to load the .so, does fpc expect RTLD_NOW or anything like that?

No, it should work.

Daniël

Daniël Mantione wrote

An FPC .so can be a perfect replacement for a C .so. I'm not aware of limitations.

Except for a bug caused by the *prt*.as -> si_*prc*.inc transition which means that currently under Linux the initialization sections are not executed:
http://www.freepascal.org/mantis/view.php?id=9089

Jonas

Thanks ,

That removes some variables from my bug hunt.

Cheers

bd

Note, this list is a few weeks old. Don't know what is merged from the "fixed" items.

1) Afaik t_linux.pas:375 should have begin..end in the else form? fixed

2) if not linking to libc, but when shared libs are used (e.g. pascal built), shared libs are not inited and finalized at all?

3) shared libs are not finalized because there is none. (they are inited in the libs pascalmain which is called in the .init section)

4) there is no .fini in the internal assembler. fixed by Florian tbt

5) problem in t_linux (initsysinitunits), in a simple test program that imports cmem, linklibc is not triggered here, because cmem's importlibrary.* contains "libc.so" not "c". (which is then copied in to linkotherlib)

6) if I temporarily fix that (so now si_c21 is chosen), the program GPFs on shutdown. libc_* constants appear to be NIL

7) without -Bsymbolic linking multiple parts (mainprogram or lib) is unreliable. However adding -Bsymbolic systematically is not doable due to http://www.freepascal.org/mantis/view.php?id=8397

8) if no libc, must we then walk the ctor/dtor tables by ourselves? These are constructed by the dynloader, but I assume the main program at least _triggers_ this walking, if the code isn't in libc to begin with.

I am running under linux - but I'm not using initalization or finalization sections, so i think i'm ok.

thanks for the info

bd