operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules
caolanm at redhat.com
Thu Mar 22 06:13:58 PDT 2012
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
> 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
More information about the LibreOffice