Bugzilla

I managed to get this working.  It required a few steps: https://hg.mozilla.org/try/rev/db7e6df47ad6d35e9754786a56689436311d73e7

1) If I link mozglue with it's own importlib imported; then all malloc calls will get redirected to je_malloc as desired. To do this I first use dlltool to generate an initial importlib and include that in the linking step.

2) the operator new/delete functions declared in Bug 1559379 : 

> On Windows, because of how some CRT static libraries are, a non-inlined operator new (thanks to some disabled STL wrapping) would end up linked against the system malloc, causing problems.

This doesn't have to be the case; as the prior step showed. So I have turned them back into forceinline for MinGW.

3) Additionally, I needed to update dependentlibs.py because we just created an infinite recursive loop

glandium - what do you think of this patch? Is there a better way to accomplish what I'm doing in rules.mk; or should I just clean it up to only apply to MinGW?

I managed to get this working with considerable help from Jacek and Martin.  It required a few steps: https://hg.mozilla.org/try/rev/db7e6df47ad6d35e9754786a56689436311d73e7

1) If I link mozglue with it's own importlib imported; then all malloc calls will get redirected to je_malloc as desired. To do this I first use dlltool to generate an initial importlib and include that in the linking step.

2) the operator new/delete functions declared in Bug 1559379 : 

> On Windows, because of how some CRT static libraries are, a non-inlined operator new (thanks to some disabled STL wrapping) would end up linked against the system malloc, causing problems.

This doesn't have to be the case; as the prior step showed. So I have turned them back into forceinline for MinGW.

3) Additionally, I needed to update dependentlibs.py because we just created an infinite recursive loop

glandium - what do you think of this patch? Is there a better way to accomplish what I'm doing in rules.mk; or should I just clean it up to only apply to MinGW?