[plt-scheme] having some trouble compiling reliable version of extension module for mzscheme3m; suggestions?

> > When a GC can happen, then you need to cooperate with the 3m collector
> > more --- in ways that I really will document soon.
>
> Thanks for the information!  Hmmm... ok, in that case, I'll have to do
> the port syncing within mzscheme rather than the C level, at least until
> I understand how to make the extension play friendly with the 3m
> collector. Not a problem.
>
> Until the documentation is available, maybe I could look at more
> examples of 3m extensions that people have written?  Do folks have
> suggestions of collections that I could look at for understanding
> things?

Hi Matthew,

Followup: Ah, I think I've sorta figured out how things work; I'll try to
describe what I've hacked up and see if it matches reality.


All C extension code that cooperates with the 3m collector appears to need
to be munged with a utility called 'xform.ss', located in
$PLT_HOME/src/mzscheme/gc2.  xform does some magical stuff that I don't
understand, but the result is another C program that cooperates with gc2.

The pre-installer.ss script in collects/openssl preprocesses all C code
through xform.ss and stores the munged files in a separate 3m
subdirectory.  These files are then effectively processed with the
compiler collection, using the special parameter:

    (parameterize ((link-variant '3m)) ...)

which the compiler collection pays attention to.  I assume, then, that
'mzc --3m' does the same sort of link-variant parameter setting when
compiling C source.

I've updated my linux-sendfile Makefile accordingly to run things through
xform.ss first, and now the package appears to work on 3m again.  Hurrah!

It would be nice if mzc was modified to add some kind of 'xform.ss'-ish
preprocessing on C source, since mzc appears already aware of gcc and the
location of the mzscheme headers.  Has anyone worked on this already?

Thanks again!