Closed Bug 613374 Opened 10 years ago Closed 10 years ago

[SeaMonkey 2.0, nightlies] new OTS code causes "gfxUserFontSet.cpp:281: undefined reference to `ots::Process(ots::OTSStream*, unsigned char const*, unsigned int, bool)'"

Categories

(Core :: Graphics, defect)

1.9.1 Branch
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Tracking Status
status2.0 --- unaffected
status1.9.2 --- unaffected
status1.9.1 --- .16-fixed

People

(Reporter: sgautherie, Assigned: Callek)

References

Details

(Keywords: verified1.9.1)

Attachments

(2 files)

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.
Attached patch c-c partSplinter Review
This ports bug 527276 and adds the lib to static-config.mk as well.
Assignee: nobody → bugspam.Callek
Status: NEW → ASSIGNED
Attachment #492065 - Flags: review?(bugzilla)
Attached patch m-c partSplinter Review
add the lib to static-config.mk in m-c too
Attachment #492066 - Flags: review?(khuey)
Attachment #492066 - Flags: review?(bugzilla)
(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.
Attachment #492066 - Flags: approval1.9.1.17?
Attachment #492066 - Flags: review?(bugzilla) → review+
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?
Attachment #492066 - Flags: approval1.9.1.17?
Attachment #492066 - Flags: approval1.9.1.17+
Attachment #492066 - Flags: approval1.9.1.16+
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)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #492065 - Flags: review?(bugzilla) → review+
(In reply to comment #13)
> I fixed Thunderbird 3.1 (probably by a different route) a while ago.

Bug 527276 comment 82 ;->
Flags: in-testsuite-
Hardware: x86 → All
(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.
Status: RESOLVED → REOPENED
Resolution: 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.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
(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.
Keywords: verified1.9.1
Blocks: 615196
(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)
You need to log in before you can comment on or make changes to this bug.