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

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 1

[Robert Kaiser]

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.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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

[Robert Kaiser]

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

Comment 4

[(not currently active) Ted Mielczarek]

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

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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

[Benjamin Smedberg]

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

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

[Benjamin Smedberg]

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.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

libxul is now required.