I gave a try to compiling SM v2.0a1pre with |--enable-libxul|. It failed ("as expected") on {{ nsAutoComplete.cpp /bin/perl .../mozilla/config/version_win.pl [...] Creating Resource file: module.res rc.exe -r -DMOZILLA_INTERNAL_API -DMOZ_SUITE=1 -DSUITE_USING_XPFE_DM=1 -DOSTYPE=\"WINNT5.0\" -DOSARCH=WINNT -I.../mozilla/xpfe/components/autocomplete/src -I. -I../../../../dist/include/xpcom -I../../../../dist/include/string -I../../../../dist/include/dom -I../../../../dist/include -I../../../../dist/include/appcomps -I../../../../dist/include/nspr -Fomodule.res .../mozilla/xpfe/components/autocomplete/src/module.rc make[8]: *** No rule to make target `../../../../dist/lib/xpcom.lib', needed by `xpautoc.dll'. Stop. }} Is it expected to fail on that file ? What would it take to fix this case ?

(In reply to comment #0) > Is it expected to fail on that file ? > What would it take to fix this case ? Neil's probably got the best view on this.

The reason it won't compile seems to be that it's trying to use the internal API, which obviously isn't available with libxul. Note that once LDAP is converted to toolkit then this can simply disappear.

(In reply to comment #2) > Note that once LDAP is converted to toolkit then this can simply disappear. Would you know a bug on this ? I can't seem to find one.

* Removed MOZILLA_INTERNAL_API * Fixed up includes * Changed mClassName into the 8-bit string it should have been

Comment on attachment 334170 [details] [diff] [review] Make it so This patch applied well on currently freezed (m-c) trunk; but I still get the same error: no more, no less :-/ >>> nsAutoComplete.cpp /bin/perl .../mozilla/config/version_win.pl [...] Creating Resource file: module.res rc.exe -r -DMOZ_SUITE=1 -DSUITE_USING_XPFE_DM=1 -DOSTYPE=\"WINNT5.0\" -DOSARCH=WINNT -I.../mozilla/xpfe/components/autocomplete/src -I. -I../../../../dist/include/xpcom -I../../../../dist/include/string -I../../../../dist/include/dom -I../../../../dist/include -I../../../../dist/include/appcomps -I../../../../dist/include/nspr -I../../../../dist/sdk/include -Fomodule.res .../mozilla/xpfe/components/autocomplete/src/module.rc make[8]: *** No rule to make target `../../../../dist/lib/xpcom.lib', needed by `xpautoc.dll'. Stop. <<< ***** Fwiw, After a (usual) non-libxul build ends, I get a 14 KB xpcom.lib in mozilla\dist\lib mozilla\dist\sdk\lib mozilla\xpcom\stub When this (attempted) libxul build fails, there is none.

I expect what is needed is two things, firstly an additional change to xpfe/components/autocomplete/src/Makefile.in (along the lines of): EXTRA_DSO_LDOPTS = \ $(LIBS_DIR) \ $(EXTRA_DSO_LIBS) \ - $(MOZ_UNICHARUTIL_LIBS) \ + $(XPCOM_GLUE_LDOPTS) \ + $(call EXPAND_LIBNAME_PATH,unicharutil_external_s,$(LIBXUL_DIST) /lib) \ $(MOZ_COMPONENT_LIBS) \ $(NULL) and secondly if that doesn't work on its own, then I expect we'll need to take xpfe/components/autocomplete out of the toolkit tier and move it into the app tier. This second bit would perhaps be easier done when TB has moved completely to toolkit autocomplete, as then we could just move the xpfe autocomplete to the /suite directory for SM.

(In reply to comment #6) > EXTRA_DSO_LDOPTS = \ > $(LIBS_DIR) \ > $(EXTRA_DSO_LIBS) \ NB: These 2 lines don't exist in the repository. I tried to add them, but it didn't make any difference. > - $(MOZ_UNICHARUTIL_LIBS) \ > + $(XPCOM_GLUE_LDOPTS) \ > + $(call > EXPAND_LIBNAME_PATH,unicharutil_external_s,$(LIBXUL_DIST) > /lib) \ I tried that (with Neil's patch), but it didn't make any difference either. > and secondly if that doesn't work on its own, Fwiw, if I remove |REQUIRES = xpcom|, I get ...\mozilla\dist\include\appcomps\nsIAutoCompleteResults.h(14) : fatal error C1083: Cannot open include file: 'nsISupportsArray.h': No such file or directory Then, would this be a "Remove nsISupportsArray" type of bug, or is it unrelated ? http://mxr.mozilla.org/mozilla-central/search?string=SupportsArray&case=on&find=%2Fxpfe%2Fcomponents%2Fautocomplete%2F > This second bit would perhaps be easier done when TB has moved completely to (TB bug 360648)

(In reply to comment #6) > I expect what is needed is two things, firstly an additional change to > xpfe/components/autocomplete/src/Makefile.in (along the lines of): This doesn't work, I've already tried. > and secondly if that doesn't work on its own, then I expect we'll need to take > xpfe/components/autocomplete out of the toolkit tier and move it into the app > tier. I've actually started recompiling with this change to determine the result. There is in fact another problem with the patch; I discovered an NS_NewISupportsArray which I need to change to do_CreateInstance.

Comment on attachment 334170 [details] [diff] [review] Make it so >diff -r 1997aa804c6c xpfe/components/autocomplete/src/nsAutoComplete.h >@@ -40,9 +40,7 @@ >-#include "nsString.h" >-#include "nsIDOMHTMLInputElement.h" >+#include "nsStringAPI.h" Then, it would seem you can - string \ - dom \ in the Makefile.in too ;-)

It looks like --enable-libxul requires --enable-places too.

(In reply to comment #9) > (From update of attachment 334170 [details] [diff] [review]) > Then, it would seem you can > - string \ > - dom \ > in the Makefile.in too ;-) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/20080823140037 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4) At least, this patch (++) works for a non-libxul build :-)

(In reply to comment #6) > + $(call EXPAND_LIBNAME_PATH,unicharutil_external_s,$(LIBXUL_DIST) /lib) \ It turns out that I don't need this line. I notice that suite/build/Makefile.in doesn't use $(XPCOM_GLUE_LDOPTS) :-(

As Mark figured, we would need to build autocomplete in tier_app.

And of course if you want your build to complete you would still need to disable wallet typeaheadfind ldap and mail.

And it looks like suite still has some internal API e.g. nsISupportsArray.

(In reply to comment #16) > And it looks like suite still has some internal API e.g. nsISupportsArray. > Yep, I was covering that in bug 397277 (ages ago), however unless you want type-unsafety in the code that uses it, then you need to either remove nsISupportsArray from the RDF code, or remove the RDF code from the bookmark code. As you also said, we've still got a few other areas to fix up as well.

(In reply to comment #16) > And it looks like suite still has some internal API e.g. nsISupportsArray. I filed bug 451871.

Comment on attachment 335188 [details] [diff] [review] mozilla-central build changes >diff -r 89c544ef96b1 xpfe/components/Makefile.in (Iiuc) This file will need (trivial) unbitrotting after bug 380786 lands.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080831161022 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4) With "--enable-libxul --enable-extensions=default,-typeaheadfind,-wallet --disable-ldap --disable-mailnews --enable-places" At last :-) *** I'm not familiar with Sunbird: someone else will have to port the fix to <calendar/build.mk>.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080831180348 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4) With "--enable-logrefcnt --enable-libxul --enable-extensions=default,-typeaheadfind,-wallet --disable-ldap --disable-mailnews --enable-places" [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080831173518 SeaMonkey/2.0a1pre] (home, debug default) (W2Ksp4) With "--enable-debug --disable-optimize --enable-trace-malloc --enable-libxul --enable-extensions=default,-typeaheadfind,-wallet --disable-ldap --disable-mailnews --enable-places" These 2 patches work fine with Libxul + Places. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080831192512 SeaMonkey/2.0a1pre] (home, debug default) (W2Ksp4) With "--enable-debug --disable-optimize --enable-trace-malloc --enable-places" They work fine with non-Libxul + Places too. *** But they fail with non-Libxul + non-Places (which replaces the following component): [ nsGlobalHistory.cpp ...\mozilla\xpfe\components\history\src\nsGlobalHistory.h(62) : fatal error C1083: Cannot open include file: 'nsIAutoCompleteSession.h': No such file or directory ] The Xpfe History component depends on the Autocomplete one... It seems also tighter related to Core/Toolkit :-/ Can it be moved to the application tier too ? Or does this have to wait for the switch to Places ?

(In reply to comment #21) > But they fail with non-Libxul + non-Places (which replaces the following > component): > [ > nsGlobalHistory.cpp > ...\mozilla\xpfe\components\history\src\nsGlobalHistory.h(62) : fatal error > C1083: Cannot open include file: 'nsIAutoCompleteSession.h': No such file or > directory > ] > > The Xpfe History component depends on the Autocomplete one... > It seems also tighter related to Core/Toolkit :-/ > > Can it be moved to the application tier too ? > Or does this have to wait for the switch to Places ? Before doing something as drastic as that, you might actually want to verify that nsIAutoCompleteSession.h is actually a required header file for the xpfe history: http://mxr.mozilla.org/comm-central/search?string=nsIAutoCompleteSession&find=xpfe%2Fcomponents%2Fhistory&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=comm-central

(In reply to comment #21) > nsGlobalHistory.cpp > ...\mozilla\xpfe\components\history\src\nsGlobalHistory.h(62) : fatal error > C1083: Cannot open include file: 'nsIAutoCompleteSession.h': No such file or > directory This include is bogus, I forgot to remove it in bug 341504. FYI I couldn't get libxul to link with --disable-places (toolkit bug?)

(In reply to comment #22) > Before doing something as drastic as that, you might actually want to verify > that nsIAutoCompleteSession.h is actually a required header file for the xpfe > history: As I remember, I had tested this last week and it failed on the (2) following headers. (But:) (In reply to comment #23) > This include is bogus, I forgot to remove it in bug 341504. I filed bug 453113 ... and it works (now) with that patch ;-> *** Neil, your patches are ready for r/sr, I think.

The new patches are unbitrotted versions of Neil's original patches. I'd love to get them into the tree as a first step of becoming able to build with libxul - but the mozilla build changes cause the static build to fail with lots of |undefined reference to `nsCOMPtr_base::foo'| messages.

Comment on attachment 455245 [details] [diff] [review] mozilla-central build changes (unbitrotted) To make this work with static builds: >-MOZILLA_INTERNAL_API = 1 Instead of deleting this, replace it with MOZILLA_INTERNAL_API = BUILD_STATIC_LIBS >-#include "nsString.h" >+#include "nsStringAPI.h" Also replace this with "nsStringGlue.h" instead.

Hmm, with the update from comment #28, it works for static and shared, but with --enable-libxul I get this: nsAutoComplete.o: In function `nsAutoCompleteResults::SetSearchString(unsigned short const*)': nsAutoComplete.cpp:(.text+0x88): undefined reference to `nsAString_internal::Assign(unsigned short const*, unsigned int)' nsAutoComplete.o: In function `nsAutoCompleteItem::SetComment(unsigned short const*)': nsAutoComplete.cpp:(.text+0xa4): undefined reference to `nsAString_internal::Assign(unsigned short const*, unsigned int)' nsAutoComplete.o: In function `nsAutoCompleteResults::GetSearchString(unsigned short**)': nsAutoComplete.cpp:(.text+0xcb): undefined reference to `ToNewUnicode(nsAString_internal const&)' nsAutoComplete.o: In function `nsAutoCompleteItem::GetComment(unsigned short**)': nsAutoComplete.cpp:(.text+0xf9): undefined reference to `ToNewUnicode(nsAString_internal const&)' nsAutoComplete.o: In function `nsAutoCompleteItem::SetClassName(char const*)': nsAutoComplete.cpp:(.text+0x2d6): undefined reference to `nsACString_internal::Assign(char const*, unsigned int)' nsAutoComplete.o: In function `nsAutoCompleteItem::GetClassName(char**)': nsAutoComplete.cpp:(.text+0x2fd): undefined reference to `ToNewCString(nsACString_internal const&)' nsAutoComplete.o: In function `nsAutoCompleteItem::SetValue(nsAString_internal const&)': nsAutoComplete.cpp:(.text+0x31d): undefined reference to `nsAString_internal::Assign(nsAString_internal const&)' nsAutoComplete.o: In function `nsAutoCompleteItem::GetValue(nsAString_internal&)': nsAutoComplete.cpp:(.text+0x337): undefined reference to `nsAString_internal::Assign(nsAString_internal const&)' nsAutoComplete.o: In function `nsAutoCompleteItem::~nsAutoCompleteItem()': nsAutoComplete.cpp:(.text+0x36a): undefined reference to `nsACString_internal::~nsACString_internal()' nsAutoComplete.cpp:(.text+0x372): undefined reference to `nsAString_internal::~nsAString_internal()' nsAutoComplete.o: In function `nsAutoCompleteItem::nsAutoCompleteItem()': nsAutoComplete.cpp:(.text+0x3d4): undefined reference to `nsAString_internal::nsAString_internal()' nsAutoComplete.cpp:(.text+0x3df): undefined reference to `nsAString_internal::nsAString_internal()' nsAutoComplete.cpp:(.text+0x3ea): undefined reference to `nsACString_internal::nsACString_internal()' nsAutoComplete.o: In function `nsAutoCompleteResults::nsAutoCompleteResults()': nsAutoComplete.cpp:(.text+0x51a): undefined reference to `nsAString_internal::nsAString_internal()' nsAutoComplete.o: In function `nsAutoCompleteResults::~nsAutoCompleteResults()': nsAutoComplete.cpp:(.text+0x13f): undefined reference to `nsAString_internal::~nsAString_internal()' nsAutoComplete.o: In function `nsAutoCompleteItem::~nsAutoCompleteItem()': nsAutoComplete.cpp:(.text+0x37f): undefined reference to `nsAString_internal::~nsAString_internal()' /usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld: libxpautocomplete.so: hidden symbol `ToNewUnicode(nsAString_internal const&)' isn't defined /usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status gmake[6]: *** [libxpautocomplete.so] Error 1

(In reply to comment #28) >>-MOZILLA_INTERNAL_API = 1 >Instead of deleting this, replace it with >MOZILLA_INTERNAL_API = BUILD_STATIC_LIBS Sorry, my fault, this should be MOZILLA_INTERNAL_API = $(BUILD_STATIC_LIBS)

Here's working patches. I tested building, I didn't test functionality really, but I don't think it should cause problems there.

OK, so those two patches are actually Neil's work, I only did unbitrotting and testing, so I looked for someone else to review, and I hope Dan is a good choice. What I tested with those are static, shared, and libxul SeaMonkey build, and a Thunderbird build (shared), and all are either at least going past autocomplete (libxul) or succeed (all others). I'd like to get those in even if the final solution might be to throw the binary code away some time, but for now, it takes one item out of the focus for being able to build libxul at all.

Neil landed most of the mozilla-central patch in his work for the XPCOM registry changes, what's left is mere build system stuff. Requesting reviews from Mark instead for those now pure build system changes.

Comment on attachment 462388 [details] [diff] [review] remaining mozilla-central build changes, v1.1 do it! [nit: it might as well be time we transition this to c-c directly? can be done in followup]

(In reply to comment #34) > do it! Thanks, done: http://hg.mozilla.org/comm-central/rev/ca1517a0dbba http://hg.mozilla.org/mozilla-central/rev/dc81ebe616ee > [nit: it might as well be time we transition this to c-c directly? can > be done in followup] Well, we still hope to be killing off the C++ part, so it wouldn't make sense to copy that over. I think moving over the XBL to suite/ should be done in the bug that cares about getting rid of the compiled part, or as a followup to that.

Pushed by frgrahl@gmx.net: https://hg.mozilla.org/comm-central/rev/67b61bb763a5 make xpfe autocomplete build with |--enable-libxul| and build it from build.mk, r=Callek, a=NPOTB for Firefox