User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20060719 Firefox/220.127.116.11 Build Identifier: Latest CVS The implementation of SetArray is declared as: inline void nsVoidArray::SetArray(Impl *newImpl, PRInt32 aSize, PRInt32 aCount, PRBool aOwner, PRBool aHasAuto) ... Because of the inline, the symbol is not properly exported on Win32. This causes problems (due to the recent Java XPCOM changes) and prevents building of xul.dll (the symbol was only required due to bug 346156, so this problem only became apparent today). Reproducible: Always Steps to Reproduce: Build XULRunner from trunk on Win32. Actual Results: See http://tinderbox.mozilla.org/showlog.cgi?log=XULRunner/1154577960.12308.gz Expected Results: Build should complete.
I don't understand. It's an inline symbol, and therefore *shouldn't* be exported.
Oh, I see, yeah, that just looks like a bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Fixed on trunk as obvious.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
-> WORKSFORME / INVALID? Or did some code actually get checked in somewhere to fix this?
Jason, you could look at the bonsai checkins and verify for yourself. Please don't second-guess my resolutions without data.
Comments were unclear. I was not second guessing, merely confused by lack of clarity over intent / actual handling of the bug. Checked in: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/glue&command=DIFF_FRAMESET&file=nsVoidArray.cpp&rev1=3.44&rev2=3.45&root=/cvsroot Much bandwidth / time could have been saved if this could have been stated originally.
You need to log in before you can comment on or make changes to this bug.