162918 - static builds are busted

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[hacker formerly known as [e-mail]]

Right now we have have 2 bits of static build bustage due to the fixes for bug
157993 & bug 121622.  These need to be fixed.

Comment 1

[hacker formerly known as [e-mail]]

The problem in both cases is that all global symbols need to be uniquely named.  

In the case of bug 157993, the ns*coderSupport classes are being duplicated in
ucvmath.so.  ucvmath.so was never converted to use ucvutil_s.  

In the case of bug 121622, the logmodule symbols need to be renamed.  I'm not
sure if that requires a seperate name to register the log module.   Probably.

Comment 2

[hacker formerly known as [e-mail]]

Attachment: make ucvmath use ucvutil_s

It builds. It runs. I make no guarantees about correctness though.

Comment 3

[rbs]

alecf mentioned that he had another iteration to merge things even further.
There are many files with just a few lines now, e.g.,
http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/nsUnicodeToZapfDingbat.cpp
http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/nsUnicodeToZapfDingbat.h
[I wonder if these can't be collapsed/grouped too (per module).]

In the meantime, if your patch works, go for it. Examples of test pages:
http://www.mozilla.org/projects/mathml/demo/basics.xhtml
http://www.mozilla.org/projects/mathml/demo/start.xml

Comment 4

[Alec Flett]

yeah, and I'm going to collapse them even further (from a simple class down to a
single function) - but I'm keeping them seperate for now

Comment 5

[hacker formerly known as [e-mail]]

Someone more mathml-savvy than I will have to verify the correctness of the
patch.  The test page rendered fine with a few ?s w & w/o my patch before I
installed the mathml fonts.  Once I installed the TexCM & Mathematica fonts on
my w2k box, the portion of the page with the formulas does not render at all and
the page height & width is extremely large.

Comment 6

[Alec Flett]

Comment on attachment 95507 [details] [diff] [review]
make ucvmath use ucvutil_s

seawood: you're very close and you've got the right idea. The only thing you
need to do now is remove the GetMaxLength() method from each of these classes -
which means removing it from both the header and the C++...

Comment 7

[hacker formerly known as [e-mail]]

Attachment: Remove GetMaxLength() functions

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

marking dup of that bug because it has a patch with review

*** This bug has been marked as a duplicate of 163217 ***

Comment 9

[hacker formerly known as [e-mail]]

Reopening as the fix for bug 163217 doesn't fix the debug builds. 

Comment 10

[hacker formerly known as [e-mail]]

Attachment: fix --disable-crypto debug builds

It turns out that we have multiple problems in debug static builds:
1) printing is using the same global variable for logging across multiple
components
2) plugins has a local non-static copy of the nsManifestLineReader class
3) NSS is doing something weird.

This patch solves the first 2 problems.  I'm not sure what's going on when we
link against NSS.  To confirm that the problem did not lie in PSM, I forced a
link against NSS_LIBS even when crypto was not enabled and the crash still
occurred.  We crash before main is even called which is usually a sign of
something crashing in a static constructor.  This seems strange as I thought
that NSS was all C, not C++.  And non-debug crypto-enabled static builds seem
to work fine.

Comment 11

[Alec Flett]

Comment on attachment 96643 [details] [diff] [review]
fix --disable-crypto debug builds

sr=alecf

I wish I knew what was up with the 2nd nsManifestLineReader :(

Comment 12

[serge (gone)]

Comment on attachment 96643 [details] [diff] [review]
fix --disable-crypto debug builds

>I wish I knew what was up with the 2nd nsManifestLineReader :(

yeah, I was thinking rename it initially, but did not:(
r=serge

Comment 13

[hacker formerly known as [e-mail]]

And now static debug builds magically work again.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What about the orange tinderboxes?  (I did a static opt build recently, and it
didn't start either.)

Comment 15

[hacker formerly known as [e-mail]]

Orange tinderboxes are not a build problem but a runtime problem.  

There seems to be something in our tinderbox scripts that breaks static builds
(or our static builds are just consistently flaky on the tinderbox).  I setup a
tinderbox on starscream and ran it over the weekend.  It went orange just like
the other static build tinderboxes.  I then did a local build using the same
mozconfig file and it worked fine.  My static debug build using my regular
mozconfig file worked fine with a 8am pull.  I just did a gcc2.95.3 -O2 build
from that same tree and it works fine as well.

As I pointed out in bug 168433, the problem on the tinderboxes appears to be
that they are failing to create an instance of the startupNotifier in main1().  

Comment 16

[Jon Granrose]

v fixed.