operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules

[Caolán McNamara]

On Thu, 2012-03-22 at 13:43 +0100, Michael Stahl wrote:
> i don't care that much about which memory allocator we use, but well the
> options are 1) link salcpprt into every executable (i.e. do it in
> solenv) 2) link it just into soffice.bin 3) don't use it at all.

If we do it at all I guess just for soffice.bin is sufficient really.

> iirc the custom allocator was only used on Linux anyway because given
> the way Windows DLLs work it's not possible to override operator new for
> the whole process

aha! I guess from the old solenv files then that libsalcpprt was linked
in for all the unix-gcc using platforms, except macosx. I wonder if
macosx was always a deliberate exclusion for some reason, or just
accidental.

> also, do we have a configure option to switch allocators?  that should
> be respected in any case if it's set.

We do indeed, but that basically affects what
rtl_allocateMemory/rtl_freeMemory points to, either custom impls or
malloc/free. So, when linking to salcpprt, new/delete ends up backing
onto whatever is requested by --with-alloc via
rtl_allocateMemory/rtl_freeMemory, so no particular extra action
required there.

C.