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

RESOLVED FIXED

Status

()

Core
Graphics
--
blocker
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: sgautherie, Assigned: Callek)

Tracking

({verified1.9.1})

1.9.1 Branch
verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(status2.0 unaffected, status1.9.2 unaffected, status1.9.1 .16-fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Johathan:
Passing t-b: "build" and "unit test".
Failing t-b: "nightly".

Robert:
"Unexpectedly", 'Linux x86-64 comm-1.9.1 build' fails too.
(Reporter)

Comment 1

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

Comment 2

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

Comment 3

7 years ago
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.
(Assignee)

Comment 5

7 years ago
I'm testing a patch for static builds atm, have not yet written or tested a patch for linux64.
(Assignee)

Comment 6

7 years ago
Created attachment 492065 [details] [diff] [review]
c-c part

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)
(Assignee)

Comment 7

7 years ago
Created attachment 492066 [details] [diff] [review]
m-c part

add the lib to static-config.mk in m-c too
Attachment #492066 - Flags: review?(khuey)
(Assignee)

Updated

7 years ago
Attachment #492066 - Flags: review?(bugzilla)
(Assignee)

Comment 8

7 years ago
(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
Attachment #492066 - Flags: review?(khuey)
Attachment #492066 - Flags: review+
(Assignee)

Comment 9

7 years ago
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+

Comment 12

7 years ago
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.
(Assignee)

Comment 15

7 years ago
(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
Last Resolved: 7 years ago
status1.9.1: --- → .16-fixed
status2.0: --- → unaffected
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Attachment #492065 - Flags: review?(bugzilla) → review+
(Reporter)

Comment 16

7 years ago
(In reply to comment #13)
> I fixed Thunderbird 3.1 (probably by a different route) a while ago.

Bug 527276 comment 82 ;->
status1.9.2: --- → unaffected
Flags: in-testsuite-
Hardware: x86 → All
(Reporter)

Comment 17

7 years ago
(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 → ---
(Assignee)

Comment 18

7 years ago
(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
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

7 years ago
(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.
(Reporter)

Comment 21

7 years ago
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
(Reporter)

Updated

7 years ago
Blocks: 615196
(Reporter)

Comment 22

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

Comment 23

7 years ago
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.