Closed
Bug 316859
Opened 19 years ago
Closed 19 years ago
undefined symbol in components/libhtmlpars.so
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: foundit, Assigned: gonufer)
References
Details
(Keywords: fixed1.8.1.17, fixed1.8.1.18, regression)
Attachments
(1 file)
681 bytes,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
dveditz
:
approval1.8.1.17+
dveditz
:
approval1.8.1.18+
asac
:
approval1.8.0.next+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a % ./seamonkey-bin ld.so.1: seamonkey-bin: fatal: relocation error: file /soft/mozilla/mozilla/dist/seamonkey/components/libhtmlpars.so: symbol __1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_: referenced symbol not found Killed Reproducible: Always Steps to Reproduce: 1. Build an actual trunk (> 20051114) 2. Start SeaMonkey 3. -> Crash Compiler: Sun Studio 10 (v5.7) and 11 (v5.8)
Reporter | ||
Updated•19 years ago
|
Version: unspecified → Trunk
Comment 1•19 years ago
|
||
don't run seamonkey-bin directly, run ./seamonkey
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•19 years ago
|
||
(In reply to comment #1) > don't run seamonkey-bin directly, run ./seamonkey > (In reply to comment #1) > don't run seamonkey-bin directly, run ./seamonkey > This is definitely not the problem, it is the way i'm running seamonkey for ages and until Nov 15 the way it worked ... BTW, same behaviour on Solaris x86 (PC) since Nov 15. PM
Reporter | ||
Comment 3•19 years ago
|
||
>
> BTW, same behaviour on Solaris x86 (PC) since Nov 15.
> PM
>
last working build on x86 I have: 2005111519
Comment 4•19 years ago
|
||
_does_ ./seamonkey work?
Reporter | ||
Comment 5•19 years ago
|
||
(In reply to comment #4) > _does_ ./seamonkey work? > no, same crash behaviour
Updated•19 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Crash at start on components/libhtmlpars.so → undefined symbol in components/libhtmlpars.so
Comment 6•19 years ago
|
||
Odd. Doesn't parser link to xpcom as needed? The function is declared in xpcom/string/public/nsReadableUtils.h and implemented in xpcom/string/src/nsReadableUtils.cpp, and uses NS_COM, so all should be ok.... The parser file in question does include nsReadableUtils.h.
Reporter | ||
Comment 7•19 years ago
|
||
Similar on actual thunderbird trunks, but here with compile/build error: % CC -o thunderbird-bin ... -lxpcom_compat Undefined first referenced symbol in file void AppendUCS4ToUTF16(const unsigned,nsAString_internal&) ../../dist/lib/components/libhtmlpars.a(nsHTMLTokens.o) ld: fatal: Symbol referencing errors. No output written to thunderbird-bin gmake[5]: *** [thunderbird-bin] Error 1
Comment 8•19 years ago
|
||
That's really odd. So what's Solaris doing differently from everything else here? This code compiles and runs fine on Mac/Linux/Windows/AIX...
Reporter | ||
Comment 9•19 years ago
|
||
(In reply to comment #8) > That's really odd. So what's Solaris doing differently from everything else > here? This code compiles and runs fine on Mac/Linux/Windows/AIX... > Some observations: % nm ./xpcom/string/src/nsReadableUtils.o | grep LossyCopyUTF16toASCII [107] | 64| 176|FUNC |GLOB |0 |2 |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_ i.e. defined ... % nm ./parser/htmlparser/src/nsHTMLTokens.o | grep AppendUCS4ToUTF16 [389] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_ here undefined! So the AppendUCS4ToUTF16 definition in components/libhtmlpars.so comes not from nsReadableUtils.o but from nsHTMLTokens.o ...
Reporter | ||
Comment 10•19 years ago
|
||
(In reply to comment #9) > > % nm ./xpcom/string/src/nsReadableUtils.o | grep LossyCopyUTF16toASCII > [107] | 64| 176|FUNC |GLOB |0 |2 > |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_ > Sorry, this should be: nm ./xpcom/string/src/nsReadableUtils.o | grep AppendUCS4ToUTF16 [155] | 8484| 120|FUNC |GLOB |0 |2 |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_
Reporter | ||
Comment 11•19 years ago
|
||
(In reply to comment #9) > > So the AppendUCS4ToUTF16 definition in components/libhtmlpars.so > comes not from nsReadableUtils.o but from nsHTMLTokens.o ... > ... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366: ... AppendUCS4ToUTF16(ENSURE_VALID_CHAR(aNCRValue), aString); ...
Reporter | ||
Comment 12•19 years ago
|
||
(In reply to comment #11) > > ... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366: > ... > AppendUCS4ToUTF16(ENSURE_VALID_CHAR(aNCRValue), aString); > ... > furher 'infected': layout/style/nsCSSScanner.cpp OK, after reverting nsHTMLTokens.cpp to v3.277 and and nsCSSScanner.cpp to v3.82 (only the AppendUCS4ToUTF16 part!, lines 879-883 in v3.83) I was able to build thunderbird again and it's running (but this is (not a| a durty) solution :-(
Reporter | ||
Comment 13•19 years ago
|
||
(In reply to comment #12) > > I was able to build thunderbird again > and it's running (but this is (not a| a durty) solution :-( > Same with seamonkey, now I'm runnig Build ID:2005111814
Comment 14•19 years ago
|
||
> ... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366:
Yes, I'm well aware of that -- I added it.
Again:
1) nsHTMLTokens.cpp includes nsReadableUtils.h, which defines this method.
2) nsReadableUtils.cpp has an implementation of this method.
3) nsHTMLTokens.cpp uses the method.
So why does this not work on Solaris, exactly? Note that of course nm shows the method as undefined in nsHTMTokens.o; the whole point is that it's in a different module, but we link against it.
Comment 15•19 years ago
|
||
==> parser
Assignee: general → mrbkap
Component: General → HTML: Parser
Product: Mozilla Application Suite → Core
QA Contact: general → parser
Assignee | ||
Comment 16•19 years ago
|
||
% nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16 [5601] | 873080| 100|FUNC |GLOB |0 |8 |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_ [1994] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_ They're not the same symbol, the mangled names are different.
Comment 17•19 years ago
|
||
Aha! That's useful! What do the demangled versions of those look like on your system?
Reporter | ||
Comment 18•19 years ago
|
||
(In reply to comment #16) > % nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16 > [5601] | 873080| 100|FUNC |GLOB |0 |8 > |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_ --> ./xpcom/string/src/nsReadableUtils.o (s. above) > [1994] | 0| 0|FUNC |GLOB |0 |UNDEF > |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_ --> ./parser/htmlparser/src/nsHTMLTokens.o (dito)
Assignee | ||
Comment 19•19 years ago
|
||
I finally have a successful trunk build with this change. The definition of AppendUCS4ToUTF16 did not match the prototype.
Comment 20•19 years ago
|
||
heh, nice. why does this work on other compilers?
Assignee: mrbkap → dougt
Status: UNCONFIRMED → NEW
Component: HTML: Parser → XPCOM
Ever confirmed: true
QA Contact: parser → xpcom
Reporter | ||
Comment 21•19 years ago
|
||
(In reply to comment #19) > Created an attachment (id=203626) [edit] > patch > > I finally have a successful trunk build with this change. The definition of > AppendUCS4ToUTF16 did not match the prototype. > .. that simple ;-), thanks ...
Updated•19 years ago
|
Assignee: dougt → gonufer
Updated•19 years ago
|
Attachment #203626 -
Flags: superreview+
Attachment #203626 -
Flags: review+
Comment 22•19 years ago
|
||
Checked in the fix. Greg, thanks for tracking this down!
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 23•16 years ago
|
||
Gah. We forgot to track this regression... We need this on branch.
Blocks: 316394
Updated•16 years ago
|
Attachment #203626 -
Flags: approval1.8.1.17?
Comment 24•16 years ago
|
||
nominating for blocking in case we re-spin (likely, just on general principal) but I think we wouldn't respin just for this. The people with compilers who need it can apply it by hand, or we can get this into the seamonkey release tag and they can pull by that. But realistically we'll end up respinning for something else and can then take this.
Comment 25•16 years ago
|
||
Comment on attachment 203626 [details] [diff] [review] patch We're respinning, please land this bug on both the regular MOZILLA_1_8_BRANCH for 1.8.1.18 as well as the release mini-branch for 1.8.1.17: GECKO181_20080827_RELBRANCH_REAL Approved for 1.8.1.17 and 1.8.1.18, a=dveditz for release-drivers
Attachment #203626 -
Flags: approval1.8.1.18+
Attachment #203626 -
Flags: approval1.8.1.17?
Attachment #203626 -
Flags: approval1.8.1.17+
Comment 26•16 years ago
|
||
Not blocking 1.8.1.17. Unfortunately short notice, but if it doesn't make it in during this window before we re-spin then it's not going to make it.
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Flags: blocking1.8.1.17?
Comment 27•16 years ago
|
||
Landed on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1.17,
fixed1.8.1.18
Comment 28•16 years ago
|
||
Unfortunately this was missed, didn't land on the SEAMONKEY_1_1_12_RELEASE tag, and broke the contrib builds for Solaris using the source release tarball. Luckily, both contrib builders (myself and Bernd Senf) for Solaris tracked down the issue and applied the patch by hand for this contrib release. It's not necessary to re-build the 1.1.12 release tarball. Because the fix is in place on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH it won't come back for SM 1.1.13+
Comment 29•16 years ago
|
||
> Unfortunately this was missed, didn't land on the SEAMONKEY_1_1_12_RELEASE tag, Uh, I didn't realize the branch involved was cut from one of the two branches in comment 27 before checkin. Someone should have spoken up at the time...
Updated•15 years ago
|
Attachment #203626 -
Flags: approval1.8.0.next?
Updated•15 years ago
|
Attachment #203626 -
Flags: approval1.8.0.next? → approval1.8.0.next+
Comment 31•15 years ago
|
||
Comment on attachment 203626 [details] [diff] [review] patch a=asac for 1.8.0
You need to log in
before you can comment on or make changes to this bug.
Description
•