RE: DrScheme/MzScheme (Glibc 2.1.3)

[Brent Fulgham <brent.fulgham@xpsystems.com>]

> The problem is that mzschemelib++ doesn't provide -DOPERATOR_NEW_ARRAY
> when it's needed.
>
Yes -- that became clear when looking at the tracing data! :-)
 
> The original gc_cpp.cc (distributed with the Boehm collector) is
> restored in plt/src/mzscheme/gc for version 102. But most programmers
> embedding MzScheme into a C++ application probably don't want 
> it, since it replaces the built-in `new' and `delete' operations. I've
already
> removed the mzschemelib++ makefile target in 102, but I can restore it
> (with -DOPERATOR_NEW_ARRAY when needed) if anyone thinks it's
> worthwhile.
> 
Most linkers (including G++2.95) correctly initialize global C++ objects
for libraries built in C++ that are dynamically loaded by an executable 
that was linked with a "C" linker.  (Did that make sense to anyone?)  There
are
a few compiler/linker combinations that apparently do not work this way,
and require the "main" executable entry to have been linked using a C++
aware linker for global initializations to take place.

This problem has been documented on the Python mailing lists when people
have written modules (compiled under C++ tools) that are loaded by a 
Python interpreter built with C tools.  Note that this is not related to
the obvious name-mangling issues you might get by not declaring the
API calls as extern "C".

So there might be cases where people need the library to be built with
the C++ features.  Although, I suppose if the main executable that uses
the mzschemelib was built with C++ tools it won't be a problem.

Thanks,

-Brent