Bug 589148 (require-libxul)

Tracking for removing shared build options (--disable-libxul)

RESOLVED FIXED

Status

enhancement
RESOLVED FIXED
9 years ago
a year ago

People

(Reporter: khuey, Unassigned)

Tracking

Trunk
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

After Gecko 2.0 we want to drop support for shared builds.  That is, the only build options will be libxul builds (the Firefox way) or static builds (the Thunderbird way).  This bug will be used to track what needs to happen before we can do that without significant pain.
Depends on: 585947

Comment 1

9 years ago
IIRC, we have a few binary tests that currently only build/run with shared builds (xpcshell thankfully works with libxul nowadays, so other tesat suites are not affected).
Also, we really should remove support for all non-libxul-based builds. Fully-static should also only be allowed in a way that does some libxul-based system. Current --enable-static is less static than libxul in some ways and a number of core features are made to be only built when libxul is on, so we should go the full way there.
Thunderbird and SeaMonkey will be libxul-based in some way soon anyhow, the ideas for non-classic libxul things go around ideas from ted and taras about "fat libxul" or linking libxul into the main app executable or such things, but at its core will be libxul-based building.
Also, current --enable-static basically defies any automated testing with our suites whatsoever (i.e. no xpcshell, which is even a requirement for mochitests, etc.) so we really want to get rid of that anyhow, as it would be really nice to be able to run tests on release builds.
(In reply to comment #1)
> IIRC, we have a few binary tests that currently only build/run with shared
> builds (xpcshell thankfully works with libxul nowadays, so other tesat suites
> are not affected).

This is correct.  Those tests will be dead.

Comment 3

9 years ago
(In reply to comment #2)
> This is correct.  Those tests will be dead.

OK, we'll just will need to make sure to hunt them down and kill them, either here or in a followup. :)
(In reply to comment #2)
> (In reply to comment #1)
> > IIRC, we have a few binary tests that currently only build/run with shared
> > builds (xpcshell thankfully works with libxul nowadays, so other tesat suites
> > are not affected).
> 
> This is correct.  Those tests will be dead.

I think we should have a (separate) bug about figuring out how to make them work in a libxul world, since they're probably useful, but not at the moment.
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > IIRC, we have a few binary tests that currently only build/run with shared
> > > builds (xpcshell thankfully works with libxul nowadays, so other tesat suites
> > > are not affected).
> > 
> > This is correct.  Those tests will be dead.
> I think we should have a (separate) bug about figuring out how to make them
> work in a libxul world, since they're probably useful, but not at the moment.

I tend to lump this into the general category of "lets make c++ unit testing not suck" (which probably deserves a bug).

Comment 6

9 years ago
Note that the current thunderbird static builds will also be broken, because they still have a separate xpcom_core. They will need to modify their build config so that xpcom_core is linked into whatever big binary they produce (binary or sharedlib).
I realized this morning that in a world where we drop intermediate static libs and link object files directly compiled tests will once again be able to see all of the symbols of interest, so these tests will actually not die but will come back to life.  It will also be much easier to write compiled tests.

Comment 8

9 years ago
I really don't understand what that means: you'd still have to link all of libxul to the compiled tests, whether it comes in static-library form or objects-as-fake-static-library form.
Depends on: 394502
Version: unspecified → Trunk
Is there a serious reason not to just make a non-libxul build configuration default to public symbols?  That seems to solve all of the pain of keeping it around.
On Linux and maybe mac, it's possible, but I'm not sure it's worth it:

You'd have to get rid of -z,defs (or link all possible libraries together to resolve symbols, but if you have A->B B<-A dependencies, even that won't work).

You probably need to still make the components be "real libraries", not XPCOM components.

On Mac, you might need to disable two-phase namespace resolution.
(In reply to comment #10)
> You'd have to get rid of -z,defs (or link all possible libraries together to
> resolve symbols, but if you have A->B B<-A dependencies, even that won't work).

Ah, I'd forgotten about that.  That approach isn't going to be work then.
Alias: libxul

Updated

9 years ago
Alias: libxul → require-libxul
Depends on: 638429
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

a year ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.