After checkin http://hg.mozilla.org/comm-central/rev/2cff0f45f0d3 the build dies here, make.exe[5]: *** No rule to make target `-lmozcairo', needed by `seamonkey.exe'. Stop. which seems to be due to missing a leading mozilla on the EXPAND_LIBNAME_PATH which is present on other libraries. Also needed for -lmozpixman.

Not sure if this should have been wrapped in an OS/2 test but other libs in configure.in call EXPAND_LIBNAME_PATH with $(DEPTH)/mozilla at the beginning of their path.

(In reply to comment #1) > Created attachment 485794 [details] [diff] [review] > Proposed fix > > Not sure if this should have been wrapped in an OS/2 test but other libs in > configure.in call EXPAND_LIBNAME_PATH with $(DEPTH)/mozilla at the beginning of > their path. Has this been tested?, I'm pretty sure MOZ_CAIRO_LIBS is used in a place where DEPTH is only as deep as the mozilla/ dir itself.

(In reply to comment #2) > (In reply to comment #1) > > Created attachment 485794 [details] [diff] [review] [details] > > Proposed fix > > > > Not sure if this should have been wrapped in an OS/2 test but other libs in > > configure.in call EXPAND_LIBNAME_PATH with $(DEPTH)/mozilla at the beginning of > > their path. > > Has this been tested?, I'm pretty sure MOZ_CAIRO_LIBS is used in a place where > DEPTH is only as deep as the mozilla/ dir itself. I've only tested on OS/2 (shared SeaMonkey). In this case TK_LIBS are linked against SeaMonkey and for OS/2 they're the MOZ_CAIRO_LIBS. I take it that they're linked for the case of a static build.

(In reply to comment #3) > (In reply to comment #2) > > Has this been tested?, I'm pretty sure MOZ_CAIRO_LIBS is used in a place where > > DEPTH is only as deep as the mozilla/ dir itself. If c-c has no use for it, why does it check for, to be in sync with m-c? > I've only tested on OS/2 (shared SeaMonkey). In this case TK_LIBS are linked > against SeaMonkey and for OS/2 they're the MOZ_CAIRO_LIBS. I take it that > they're linked for the case of a static build. We should remove MOZ_CAIRO_CFLAGS and MOZ_CAIRO_LIBS from the TK_CFLAGS and TK_LIBS in both c-c and m-c configure. I tested it with Minefield, and libxul-SeaMonkey as well as with Thunderbird-3.1.5pre (i.e. 1.9.2 branch, where TB is linked statically). Maybe you want to try another combination of comm and mozilla and non-libxul shared build.

I have a SeaMonkey non-libxul shared build building now. I'd guess that the TK flags are needed in this case. I forgot about static builds no longer being supported.

Comment on attachment 485794 [details] [diff] [review] Proposed fix ok, I'm relatively sure this won't drastically break anything. and it /seems/ to only matter in _static_ builds anyway, even though its not supported. So I'm ok with this landing, to-whoever-lands, please land in its own push so we can catch burning a bit more obviously.

Checked in: http://hg.mozilla.org/comm-central/rev/fd65c2f5c8d3