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)
don't run seamonkey-bin directly, run ./seamonkey
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
(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
> > BTW, same behaviour on Solaris x86 (PC) since Nov 15. > PM > last working build on x86 I have: 2005111519
_does_ ./seamonkey work?
(In reply to comment #4) > _does_ ./seamonkey work? > no, same crash behaviour
13 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Crash at start on components/libhtmlpars.so → undefined symbol in components/libhtmlpars.so
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.
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: *** [thunderbird-bin] Error 1
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...
(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  | 64| 176|FUNC |GLOB |0 |2 |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_ i.e. defined ... % nm ./parser/htmlparser/src/nsHTMLTokens.o | grep AppendUCS4ToUTF16  | 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 ...
(In reply to comment #9) > > % nm ./xpcom/string/src/nsReadableUtils.o | grep LossyCopyUTF16toASCII >  | 64| 176|FUNC |GLOB |0 |2 > |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_ > Sorry, this should be: nm ./xpcom/string/src/nsReadableUtils.o | grep AppendUCS4ToUTF16  | 8484| 120|FUNC |GLOB |0 |2 |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_
(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); ...
(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 :-(
(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
> ... 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.
Assignee: general → mrbkap
Component: General → HTML: Parser
Product: Mozilla Application Suite → Core
QA Contact: general → parser
% nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16  | 873080| 100|FUNC |GLOB |0 |8 |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_  | 0| 0|FUNC |GLOB |0 |UNDEF |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_ They're not the same symbol, the mangled names are different.
Aha! That's useful! What do the demangled versions of those look like on your system?
(In reply to comment #16) > % nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16 >  | 873080| 100|FUNC |GLOB |0 |8 > |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_ --> ./xpcom/string/src/nsReadableUtils.o (s. above) >  | 0| 0|FUNC |GLOB |0 |UNDEF > |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_ --> ./parser/htmlparser/src/nsHTMLTokens.o (dito)
Created attachment 203626 [details] [diff] [review] patch I finally have a successful trunk build with this change. The definition of AppendUCS4ToUTF16 did not match the prototype.
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
(In reply to comment #19) > Created an attachment (id=203626)  > patch > > I finally have a successful trunk build with this change. The definition of > AppendUCS4ToUTF16 did not match the prototype. > .. that simple ;-), thanks ...
Checked in the fix. Greg, thanks for tracking this down!
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → FIXED
Gah. We forgot to track this regression... We need this on branch.
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 on attachment 203626 [details] [diff] [review] patch We're respinning, please land this bug on both the regular MOZILLA_1_8_BRANCH for 184.108.40.206 as well as the release mini-branch for 220.127.116.11: GECKO181_20080827_RELBRANCH_REAL Approved for 18.104.22.168 and 22.214.171.124, a=dveditz for release-drivers
Not blocking 126.96.36.199. 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.
Landed on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH.
Keywords: fixed188.8.131.52, fixed184.108.40.206
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+
> 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...
Attachment #203626 - Flags: approval1.8.0.next? → approval1.8.0.next+
You need to log in before you can comment on or make changes to this bug.