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

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.

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.

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

C.

diff --git a/desktop/Executable_soffice.bin.mk b/desktop/Executable_soffice.bin.mk
index e0c5891..5c86c92 100644
--- a/desktop/Executable_soffice.bin.mk
+++ b/desktop/Executable_soffice.bin.mk
@@ -100,6 +100,18 @@ $(eval $(call gb_Executable_set_ldflags,\
 
 endif
 
+#TO-DO fixme, pre-gbuild, executables, unless explicitly
+#marked otherwise, default linked to salcpprt which
+#contains the global new stuff which reroutes new
+#to our internal allocators
+ifeq ($(COM)-$(OS),GCC-LINUX)
+
+$(eval $(call gb_Executable_add_ldflags,$(sofficebin),\
+    -Wl$(COMMA)--whole-archive -lsalcpprt -Wl$(COMMA)--no-whole-archive \
+))
+
+endif
+
 $(eval $(call gb_Executable_add_nativeres,$(sofficebin),sofficebin/src))
 
 # vim: set ts=4 sw=4 et: