Johathan: Passing t-b: "build" and "unit test". Failing t-b: "nightly". Robert: "Unexpectedly", 'Linux x86-64 comm-1.9.1 build' fails too.

(In reply to comment #0) > Robert: > "Unexpectedly", 'Linux x86-64 comm-1.9.1 build' fails too. Fwiw, dep/mozconfig are the same for Linux and Linux64.

The passing ones might just be because they don't clobber, while nightlies always clobber.

Neil, Justin, Mark, may this be connected with not using libxul on the 1.9.1 branch? Do you have any ideas how to fix this? We'd like to go for building another security update for SeaMonkey 2.0.x soon, but we'd need it to compile for that...

It always helps to include a brief log... The nightly builds are failing with: ../../mozilla/staticlib/libthebes.a(gfxUserFontSet.o): In function `gfxUserFontSet::OnLoadComplete(gfxFontEntry*, unsigned char const*, unsigned int, unsigned int)': /builds/slave/comm-1.9.1-linux-nightly/build/mozilla/gfx/thebes/src/gfxUserFontSet.cpp:281: undefined reference to `ots::Process(ots::OTSStream*, unsigned char const*, unsigned int, bool)' collect2: ld returned 1 exit status whilst linking seamonkey-bin The linux 64 bit build is failing with: /usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can not be used when making a shared object; recompile with -fPIC and this is linking thebes. So nightly versus dep is different... what does SeaMonkey do different in terms of build configuration? nightly are static, dep are shared. Once you know that, its slightly more obvious that the nightly bustage is due to not linking something into seamonkey-bin, and given where gfxUserFontSet.cpp is I'd bet that's not being linked against the thebes library. The Thunderbird part of the puzzle is caused by the fact that on comm-1.9.1 Thunderbird dep & nightly builds get fixed to a specific revision until the next release, so I suspect when we hit that we'll get the issues SM is seeing as Thunderbird doesn't link against thebes at the moment either. Swapping to the linux 64 bit issue, that is typically just needing a FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the thebes/src/Makefile.in.

I'm testing a patch for static builds atm, have not yet written or tested a patch for linux64.

This ports bug 527276 and adds the lib to static-config.mk as well.

add the lib to static-config.mk in m-c too

(In reply to comment #6) > c-c part (In reply to comment #7) > m-c part c-191 and m-191 actually. And everything built and linked fine in my test with both these patches

Comment on attachment 492066 [details] [diff] [review] m-c part requesting approval for this part now. Its safe, not used for Firefox and fixes SeaMonkey and Thunderbird builds, so that we can have nightlies and have a release ready for the next security drill. khuey is official reviewer, Mark is requested but not official for the m-c part here, its just a formality for this bug as a whole.

Comment on attachment 492065 [details] [diff] [review] c-c part Not tested this but it looks fine. a=Standard8 for 1.9.1 landing as well.

Comment on attachment 492066 [details] [diff] [review] m-c part Approved for 1.9.1.17, a=dveditz for release-drivers. I assume we'll want to land this on the _RELBRANCH so it makes the 1.9.1.16-based releases. Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well?

FYI, the relbranch is GECKO19116_20101122_RELBRANCH.

(In reply to comment #11) > Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well? No, I believe I fixed Thunderbird 3.1 (probably by a different route) a while ago.

Just to clarify comment 11 and 12: please _do_ land on GECKO19116_20101122_RELBRANCH and base your builds on that changeset. If we end up taking additional fixes Firefox will pick it up, and if not it we'll still have code-level compatibility on this release.

(In reply to comment #11) > Comment on attachment 492066 [details] [diff] [review] > m-c part > > Approved for 1.9.1.17, a=dveditz for release-drivers. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3b74f6a6bc71 > I assume we'll want to > land this on the _RELBRANCH so it makes the 1.9.1.16-based releases. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/54745ba055f0 > Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well? If any of those here want a 1.9.2 patch to sync it and be "safe" there, I'm happy to provide it. (In reply to comment #10) > Comment on attachment 492065 [details] [diff] [review] > c-c part > > Not tested this but it looks fine. a=Standard8 for 1.9.1 landing as well. http://hg.mozilla.org/releases/comm-1.9.1/rev/0c235bd0797a (setting status2.0 to unaffected, but really its wontfix)

(In reply to comment #13) > I fixed Thunderbird 3.1 (probably by a different route) a while ago. Bug 527276 comment 82 ;->

(In reply to comment #2) > The passing ones might just be because they don't clobber, while nightlies > always clobber. Hum... According to (new) SM Clobberer page, no SM 2.0 build was clobbered that way yet :-| This lets us wonder whether this is truly Linux64 specific or not. Moreover, if this bug is clobber related, it would mean there is/was a dependency issue somewhere, wouldn't it? I'm clobberring 'build' on cb-seamonkey-linux-02 and cb-seamonkey-linux64-01, fwiw: submitted at "2010-11-22 21:43:07 PST". (This is also a check on my side as it's the first time I use this tool.) (In reply to comment #4) > Swapping to the linux 64 bit issue, that is typically just needing a > FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the > thebes/src/Makefile.in. This part remains to be fixed.

(In reply to comment #17) > (In reply to comment #2) > > The passing ones might just be because they don't clobber, while nightlies > > always clobber. > > Hum... > (In reply to comment #4) > > Swapping to the linux 64 bit issue, that is typically just needing a > > FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the > > thebes/src/Makefile.in. > > This part remains to be fixed. I want to spin it out to another bug, as it is two separate issues to fix (though both the same cause). I'll file at latest tomorrow.

(In reply to comment #17) > This lets us wonder whether this is truly Linux64 specific or not. Fwiw, TB 'Linux x86-64 comm-1.9.2 check' is green.

(In reply to comment #17) > (In reply to comment #2) > > The passing ones might just be because they don't clobber, while nightlies > > always clobber. > > Hum... > > According to (new) SM Clobberer page, no SM 2.0 build was clobbered that way > yet :-| > This lets us wonder whether this is truly Linux64 specific or not. > > Moreover, if this bug is clobber related, it would mean there is/was a > dependency issue somewhere, wouldn't it? Re-read my comment 4. The effect is caused by the dep/nightly builders on SeaMonkey having two different configurations.

verified1.9.1, per http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290501537.1290504808.3890.gz Linux x86-64 comm-1.9.1 nightly on 2010/11/23 00:38:57 ***** (In reply to comment #20) > (In reply to comment #17) > > Moreover, if this bug is clobber related, it would mean there is/was a > > dependency issue somewhere, wouldn't it? > > Re-read my comment 4. The effect is caused by the dep/nightly builders on > SeaMonkey having two different configurations. I'm not sure we're talking about the same thing: I think I understood your comment 4, but, in comment 17, I was wondering about Linux64 dep versus 3 other deps.

(In reply to comment #17) > I'm clobberring 'build' on cb-seamonkey-linux-02 and cb-seamonkey-linux64-01, > fwiw: submitted at "2010-11-22 21:43:07 PST". cb-seamonkey-linux-02: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290490267.1290494178.23268.gz&fulltext=1 Linux comm-1.9.1 build on 2010/11/22 21:31:07 free-space clobber { Checking clobber URL: ... comm-1.9.1-linux:Our last clobber date: None comm-1.9.1-linux:Server clobber date: None TinderboxPrint: free-space clobber } started was just before I requested a clobber. http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290515038.1290519161.23185.gz&fulltext=1 Linux comm-1.9.1 build on 2010/11/23 04:23:58 { Checking clobber URL: ... comm-1.9.1-linux:Our last clobber date: 2010-11-22 21:43:07 comm-1.9.1-linux:Server clobber date: 2010-11-22 21:43:07 } should be the one to be clobbered. Though it doesn't explicitly report clobbering anywhere, afaict. (I thought "forced clobber" or something should be printed...) cb-seamonkey-linux64-01: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290484640.1290484824.14401.gz&fulltext=1 Linux x86-64 comm-1.9.1 build on 2010/11/22 19:57:20 { Checking clobber URL: ... comm-1.9.1-linux64:Our last clobber date: 2010-11-20 03:53:27 comm-1.9.1-linux64:Server clobber date: None comm-central-trunk-linux64:Our last clobber date: 2010-11-15 21:33:20 comm-central-trunk-linux64:Server clobber date: 2010-11-08 20:30:00 } http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290518787.1290519669.26174.gz&fulltext=1 Linux x86-64 comm-1.9.1 build on 2010/11/23 05:26:27 { Checking clobber URL: ... comm-1.9.1-linux64:Our last clobber date: 2010-11-22 21:43:07 comm-1.9.1-linux64:Server clobber date: 2010-11-22 21:43:07 comm-central-trunk-linux64:Our last clobber date: 2010-11-15 21:33:20 comm-central-trunk-linux64:Server clobber date: 2010-11-08 20:30:00 } linux is still green, linux64 is still red: either clobber didn't work or the issue is (confirmed as) linux64 specific. (In reply to comment #18) > I want to spin it out to another bug, as it is two separate issues to fix > (though both the same cause). I'll file at latest tomorrow. I eventually filed bug 615196.

I just stumbled on this issue in seamonkey 2.0.11 on RHEL5. All previous versions (2.0.x up to and including 2.0.10) did build and work fine as linux64. Something changed in 2.0.11 which is causing my rpmbuild to fail: c++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -finline-limit=50 -I/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/include/cairo -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -fPIC -shared -Wl,-z,defs -Wl,-h,libthebes.so -o libthebes.so cairo-xlib-utils.o gfxASurface.o gfxAlphaRecovery.o gfxBlur.o gfxContext.o gfxImageSurface.o gfxFont.o gfxFontMissingGlyphs.o gfxFontTest.o gfxFontUtils.o gfxMatrix.o gfxPath.o gfxPattern.o gfxPlatform.o gfxRect.o gfxSkipChars.o gfxTextRunCache.o gfxTextRunWordCache.o gfxUserFontSet.o gfxPangoFonts.o gfxXlibSurface.o gfxPlatformGtk.o gfxGdkNativeRenderer.o gfxPDFSurface.o gfxPSSurface.o gfxFontconfigUtils.o nsUnicodeRange.o -lpthread -Wl,-rpath-link,/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin -Wl,-rpath-link,/usr/lib ../../../gfx/cairo/cairo/src/libmozcairo.a ../../../gfx/cairo/libpixman/src/libmozlibpixman.a -L/usr/lib64 -lXrender -lfreetype -lfontconfig /usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib/libunicharutil_s.a -L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin -lxpcom -lxpcom_core -L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lz ../../../gfx/qcms/libmozqcms.a ../../../gfx/ots/src/libmozots.a -L/lib64 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lz -L/usr/lib64 -lX11 -L/lib64 -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lasound -ldl -lm /usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status gmake[7]: *** [libthebes.so] Error 1 gmake[7]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes/src' gmake[6]: *** [libs] Error 2 gmake[6]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes' gmake[5]: *** [libs] Error 2 gmake[5]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx' gmake[4]: *** [libs_tier_gecko] Error 2 gmake[4]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla' gmake[3]: *** [tier_gecko] Error 2 gmake[3]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla' gmake[2]: *** [default] Error 2 gmake[2]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.2979 (%build)