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

[Michael Stahl]

On 22/03/12 13:14, Caolán McNamara wrote:
> Traditionally we linked our binaries with libsalcpprt which provides
> global operator new/delete etc to reroute those allocations through our
> sal rtl_allocateMemory and rtl_freeMemory
> 
> Somewhere along the line, perhaps gbuild conversions, this has gotten
> lost. I assume this is an oversight, and not deliberate ? I see very
> little mention of salcpprt in solenv/gbuild but you can see all the
> remnants in the older build system in solenv. i.e. by default we linked
> to it when creating executables with some executables excluded from the
> scheme.

ah that was hacked into solenv directly? didn't know that.

> e.g. attached is a hack to link soffice.bin under Linux to salcpprt to
> make it work again for me locally for some hacking.

looks fine for a local fix except perhaps it would be better style to
use gb_Executable_add_libs instead of gb_Executable_add_ldflags.

> Should we restore linking to libsalcpprt by default again ? I'm unsure
> what the windows link lines should be.

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.

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, you'd have to link it into every DLL. (also, iirc on
windows in general it's necessary that objects are freed by the DLL that
allocated them because every DLL could have different allocator... well
at least all the ones built by our build system probably use the same
allocator in practice).

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