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:
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
