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

RESOLVED FIXED

Status

SeaMonkey
Build Config
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: sgautherie, Assigned: neil@parkwaycc.co.uk)

Tracking

Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 7 obsolete attachments)

(Reporter)

Description

9 years ago
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 ?
(Reporter)

Updated

9 years ago
Blocks: 450799
(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.
(Assignee)

Comment 2

9 years ago
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.
(Reporter)

Comment 3

9 years ago
(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.
(Assignee)

Comment 4

9 years ago
Created attachment 334170 [details] [diff] [review]
Make it so

* Removed MOZILLA_INTERNAL_API
* Fixed up includes
* Changed mClassName into the 8-bit string it should have been
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #334170 - Flags: review?(iann_bugzilla)
(Reporter)

Comment 5

9 years ago
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.
(Reporter)

Updated

9 years ago
Flags: in-testsuite-
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.
(Reporter)

Comment 7

9 years ago
(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)
(Assignee)

Comment 8

9 years ago
(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.
(Reporter)

Comment 9

9 years ago
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 ;-)
(Assignee)

Comment 10

9 years ago
It looks like --enable-libxul requires --enable-places too.
(Reporter)

Comment 11

9 years ago
(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 :-)
(Assignee)

Comment 12

9 years ago
(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) :-(
(Assignee)

Comment 13

9 years ago
Created attachment 335187 [details] [diff] [review]
comm-central build changes

As Mark figured, we would need to build autocomplete in tier_app.
Attachment #334170 - Attachment is obsolete: true
Attachment #334170 - Flags: review?(iann_bugzilla)
(Assignee)

Comment 14

9 years ago
Created attachment 335188 [details] [diff] [review]
mozilla-central build changes
(Assignee)

Comment 15

9 years ago
And of course if you want your build to complete you would still need to disable wallet typeaheadfind ldap and mail.
(Assignee)

Comment 16

9 years ago
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.
(Reporter)

Comment 18

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

I filed bug 451871.
Blocks: 394502
No longer blocks: 397277
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Comment 19

9 years ago
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.
(Reporter)

Updated

9 years ago
Depends on: 380786
(Reporter)

Comment 20

9 years ago
Created attachment 336255 [details] [diff] [review]
(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>.
(Reporter)

Updated

9 years ago
Attachment #335188 - Attachment is obsolete: true
(Reporter)

Comment 21

9 years ago
[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
(Assignee)

Comment 23

9 years ago
(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?)
(Reporter)

Updated

9 years ago
Depends on: 453113
(Reporter)

Comment 24

9 years ago
(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.
QA Contact: build-config → build-config
(Reporter)

Updated

7 years ago
Duplicate of this bug: 555459

Comment 26

7 years ago
Created attachment 455242 [details] [diff] [review]
comm-central build changes (unbitrotted)
Attachment #335187 - Attachment is obsolete: true

Comment 27

7 years ago
Created attachment 455245 [details] [diff] [review]
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.
Attachment #336255 - Attachment is obsolete: true
(Assignee)

Comment 28

7 years ago
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

7 years ago
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
(Assignee)

Comment 30

7 years ago
(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

7 years ago
Created attachment 455506 [details] [diff] [review]
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.
Attachment #455242 - Attachment is obsolete: true
Attachment #455506 - Flags: review?(dmose)

Comment 32

7 years ago
Created attachment 455517 [details] [diff] [review]
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.
Attachment #455245 - Attachment is obsolete: true
Attachment #455517 - Flags: review?(dmose)

Comment 33

7 years ago
Created attachment 462388 [details] [diff] [review]
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.
Attachment #455517 - Attachment is obsolete: true
Attachment #462388 - Flags: review?(bugzilla)
Attachment #455517 - Flags: review?(dmose)

Updated

7 years ago
Attachment #462388 - Attachment description: remaining mozilla-central build changes, v1 → remaining mozilla-central build changes, v1.1

Updated

7 years ago
Attachment #455506 - Flags: review?(dmose) → review?(bugzilla)
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]
Attachment #462388 - Flags: review?(bugzilla) → review+

Updated

7 years ago
Attachment #455506 - Flags: review?(bugzilla) → review+

Comment 35

7 years ago
(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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.