Right now it cause the inclusion of nsString: nsStaticComponent.h -> nsComponentLoader.h -> nsHashtable.h -> nsString.h So it's not possible to do a static build of code using nsEmbedString. We seem to only need the nsGetModuleProc definition from nsComponentLoader.h. Maybe it would be possible to move it in another file ?
More precisely the problem is that you cant include nsStaticComponent.h and use embed string in the same file. It would be probably possible to work around the problem in gtkmozembed using a separate file or something, though I think it would be much more convenient to cleanup these headers if possible.
Comment on attachment 148453 [details] [diff] [review] possible fix Does something like this make sense?
Created attachment 148565 [details] [diff] [review] fix missing stdio inclusion
Comment on attachment 148565 [details] [diff] [review] fix missing stdio inclusion For gtkmozembed the alternative is to add an Init function to EmbedComponents.cpp (there embed strings are not included) and do NSGetStaticModuleInfo = gtk_getModuleInfo; in it instead of in EmbedPrivate.cpp. Not sure what I like better, I guess it depend if we expect to hit the same problem somewhere else in the future. Up to you.
Comment on attachment 148565 [details] [diff] [review] fix missing stdio inclusion looks fine.
Comment on attachment 148565 [details] [diff] [review] fix missing stdio inclusion r=darin kill extra newline at the end of nsModule.h shouldn't we put @status FROZEN in this file? and shouldn't it be exported to the SDK? (add to SDK_HEADERS in the Makefile?) or is there some reason not to include this in the gecko sdk?
I don't think that the current static component loader is sufficiently settled to freeze it. In particular, we're probably going to need to support multi-tier static components (from libxul and client apps).
Created attachment 148684 [details] [diff] [review] kill extra newline