450781 - "No rule to make target .../xpcom.lib" compiling <nsAutoComplete.cpp> with |--enable-libxul|

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

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 ?

Comment 1

[Mark Banner (:standard8)]

(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.

Comment 2

[[e-mail]]

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.

Comment 3

[Serge Gautherie (:sgautherie)]

(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.

Comment 4

[[e-mail]]

Attachment: Make it so

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

Comment 5

[Serge Gautherie (:sgautherie)]

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.

Comment 6

[Mark Banner (:standard8)]

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.

Comment 7

[Serge Gautherie (:sgautherie)]

(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)

Comment 8

[[e-mail]]

(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 9

[Serge Gautherie (:sgautherie)]

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 ;-)

Comment 10

[[e-mail]]

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

Comment 11

[Serge Gautherie (:sgautherie)]

(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 :-)

Comment 12

[[e-mail]]

(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) :-(

Comment 13

[[e-mail]]

Attachment: comm-central build changes

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

Comment 14

[[e-mail]]

Attachment: mozilla-central build changes

Comment 15

[[e-mail]]

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

Comment 16

[[e-mail]]

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

Comment 17

[Mark Banner (:standard8)]

(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.

Comment 18

[Serge Gautherie (:sgautherie)]

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

I filed bug 451871.

Comment 19

[Serge Gautherie (:sgautherie)]

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.

Comment 20

[Serge Gautherie (:sgautherie)]

Attachment: (Av2a) mozilla-central build changes

[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>.

Comment 21

[Serge Gautherie (:sgautherie)]

[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 ?

Comment 22

[Mark Banner (:standard8)]

(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

Comment 23

[[e-mail]]

(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?)

Comment 24

[Serge Gautherie (:sgautherie)]

(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.

Comment 26

[Robert Kaiser]

Attachment: comm-central build changes (unbitrotted)

Comment 27

[Robert Kaiser]

Attachment: mozilla-central build changes (unbitrotted)

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 28

[[e-mail]]

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.

Comment 29

[Robert Kaiser]

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

Comment 30

[[e-mail]]

(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)

Comment 31

[Robert Kaiser]

Attachment: working comm-central build changes, v1

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

Comment 32

[Robert Kaiser]

Attachment: working mozilla-central build changes, v1

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.

Comment 33

[Robert Kaiser]

Attachment: remaining mozilla-central build changes, v1.1

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 34

[Justin Wood (:Callek)]

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]

Comment 35

[Robert Kaiser]

(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.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
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