332384 - Eliminate dependency on xpcomObsoleteModule (libxpcom_compat)

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Mark Mentovai]

xpcomObsoleteModule (libxpcom_compat) is not necessary and not used.  Taking it out of the distribution will save some space.

Comment 1

[Mark Mentovai]

Attachment: Do it

Comment 2

[Håkan Waara]

r=me if everything still compiles as it should. ;)

Comment 3

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 216857 [details] [diff] [review]
Do it

r=pink

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 216857 [details] [diff] [review]
Do it

This is the old patches police.  mento, did this ever land?

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Someone remind me later this week and I'll see about unbitrotting this.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: trunk, unbitrotted

You know, the ac_add_options stuff has moved twice since the initial patch ;)

I haven't spent the 6 hrs needed to do full rebuilds, but I have rebuilt just Camino, trunk/branch, static/nonstatic, and those four bits are all fine.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: branch, unbitrotted

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 269230 [details] [diff] [review]
branch, unbitrotted

xpinstall requires xpcomObsolete on the branch, and we apparently build xpinstall everywhere (even though I don't think we use it).

I'll run some more tests on branch and trunk and see if we can turn on --disable-xpinstall both places and be rid of both these things in one fell swoop.

Comment 9

[Håkan Waara]

Just throwing this out, it might be totally off-base: is XPInstall needed for the Mozilla update stuff (.MARs and what-not) ? 

That could be worth having a quick look at, before working too hard on --disable-xpinstall.

Comment 10

[Håkan Waara]

This of course on the assumption that we might want to use Mozilla update. Of course that decision has not been 100% made yet...

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The update stuff is really unclear; some places it says it was designed to avoid all the complexity of xpinstall, and some places it says it reuses xpinstall code.  I believe sspitzer told Sam there was very, very little of "Gecko" involved in updater, though.

Anyway, given the fact that we don't currently package any xpinstall stuff, the sole change is a line in confvars.sh on the trunk, so on or off really doesn't matter.  Trunk builds fine both ways with xpcomObsolete and xpinstall both disabled.

On the branch, non-static builds fine with xpinstall disabled as well as xpcomObsolete disabled.  Static, however, fails when linking mozilla-bin, because...

ld: warning -L: directory name (-L../../dist/bin) does not exist
ld: can't locate file for: -lxpcom_compat

Hello!?  We've disabled xpcomObsolete!  A bit of MXRing around xpfe/bootstrap and I can't figure out where that's being set up.  So that looks like there's a bug there.

Unless someone else wants to go digging around on the branch and figuring out how to make mozilla-bin not try to link xpcomObsolete when xpcomObsolete is disabled, my recommendation is to just land the unbitrotted trunk patch (only removing xpcomObsolete and its libs) as-is.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 269229 [details] [diff] [review]
trunk, unbitrotted

CmXULAppInfo and new project bitrotted this one.

Comment 13

[Stuart Morgan]

It is indeed a branch bug; config/static-config.mk on branch has:

ifndef MINIMO
STATIC_EXTRA_LIBS += $(MOZ_XPCOM_OBSOLETE_LIBS)
endif

Whereas on trunk it's been changed to |ifndef MOZ_NO_XPCOM_OBSOLETE|

It's probably not worth getting branch approval for that change. I can unbitrot and land the trunk version if no-one else gets to it in the next few days.

Comment 14

[Mark Mentovai]

I have no idea why I never checked this in last year or why Smokey's patch never got checked in this year, but we should do this.

Comment 15

[Stuart Morgan]

Re-un-bitrotted and landed on trunk.

Comment 16

[Mark Mentovai]

Who else wants to take this on the branch?  I like killing unused junk.

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If you want to wrangle branch approval for comment 13, I'm all in favor of killing xpcom_obsolete (and xpinstall, bug 332397) on the branch.

Comment 18

[Mark Mentovai]

I checked this in on the branch without the mozconfig change.  That'll let xpcomObsoleteModule (libxpcom_compat) be built, so that mozilla-bin can link against it.  We won't use it in Camino, though.  Comment 13 can be addressed separately and then we can drop it from our mozconfig.

Comment 19

[Mark Mentovai]

Comment 13 is bug 408935, fixes --disable-xpcom-obsolete on the 1.8 branch.

Bug 408959 has the mozconfig change, uses --disable-xpcom-obsolete in Camino on the 1.8 branch.