793638 - Set LD_BIND_NOW=1 when running all tests on linux/linux64

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P4)

Description

[Mike Hommey [:glandium]]

The build and test environments are different, and the current m-c builds can actually fail at random times because of missing symbols in the test environment, depending on whether some code paths are activated at runtime. For instance, Christian Holler was getting errors on try because of a missing g_malloc_n symbol triggered from mozcontainer.c after we switched to mock builds, although current m-c tests don't trip on that, although the symbol *is* currently missing.

Considering the test environment is pretty close to the minimum runtime environment we require, it would be worth forcing all symbols to be resolved at startup instead of runtime so that any missing symbol is spotted early, not at some random time where we add tests that trigger code using them. Since doing so has an impact on startup time, it should only be done on test suites where startup time is not important (everything but some talos ; might as well keep things simple and do it on everything but talos).

Note this can't be done on m-c until bug 793634 lands.

I think this should be done on the tinderbox scripts side, instead of runtests.py and friends.

Comment 1

[[e-mail] (:bhearsum)]

(In reply to Mike Hommey [:glandium] from comment #0)
> I think this should be done on the tinderbox scripts side, instead of
> runtests.py and friends.

Is there a reason we wouldn't want these set when developers are running tests locally? If not, I would suggest that the harness' are the more appropriate place.

Comment 2

[Mike Hommey [:glandium]]

(In reply to Ben Hearsum [:bhearsum] from comment #1)
> (In reply to Mike Hommey [:glandium] from comment #0)
> > I think this should be done on the tinderbox scripts side, instead of
> > runtests.py and friends.
> 
> Is there a reason we wouldn't want these set when developers are running
> tests locally?

There's not much added value from developers doing that, because they are unlikely to have gtk/glib compatibility issues on their (usually recent) environments.

Comment 3

[[e-mail] (:bhearsum)]

This probably belongs in mach at this point, considering we have lots of other automation decisions/env vars in there. Not sure if it still matters though.