[fpc-pascal] fpc and boehm

[Marco van de Voort]

> > 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?
> 
> An FPC .so can be a perfect replacement for a C .so. I'm not aware of 
> limitations.

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.