sheep 235 > CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-01 2001/01/31 sheep 236 > uname -a SunOS sheep 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-60 sheep 237 > Trying to build the current tip with --enable-ldap on this machine causes CC to segfault while compiling a switch statement in nsLDAPMessage.cpp.

emose: Please match exact comiler version in your #if statement instead of killing all versions of Sun Workshop... ... and/or place a comment which _exact_ version has this problem...

r=rich.burridge@sun.com for currently #ifdef'ing this out. I've given the compiler group a heads-up on this, and hopefully they will be trying to build/test this soon. Thanks.

sr=sfraser

Fix checked in.

There's a Sun WorkShop 6 update 1 patch available which fixes the compile problem. The patches are 109508-03 (sparc) & 109509-03 (intel). I've verified that with these patches you can compile nsLDAPMessage.cpp without the #ifdef.

What is __SUNPRO_CC set to when these patches are installed?

reassign to Olga as QA contact

__SUNPRO_CC is set to 0x520. The value is not changed by the patch. I did my test compile by commenting out the "#if __SUNPRO_CC != 0x520" which was in nsLDAPMessage.cpp.

Shirley Woo: % CC -V usually tells me the patch level of Workshop, too - what about a cpp symbol to check that from within code ?

Roland, there is no such preprocessor symbol to determine the patch level. Only the version of the Forte compilers, which isn't going to help here.

> Roland, there is no such preprocessor symbol to determine the patch level. > Only the version of the Forte compilers, which isn't going to help here. I know that. That was more an RFE to add such a cpp symbol to have a way to work around those issues in future versions of Workshop...

Given how rarely this happens, and since it's only a logging thing, I'm inclined to leave the code the way it is rather than forcing everyone who has this compiler to get the patch just to be able to build Mozilla. Reopen if you have strong feelings otherwise.

Getting patches to a commercial product is a reasonable requirement, Dan. It happens all the time: if you have Solaris, you probably get periodic "Maintenance Updates", a series of patches that fix problems found in Solaris. Same for the compiler products. Forte 6 is still fairly early on; customers who want to use this compiler will be upgrading, and it's not that difficult to do. So if the #ifdef was only to work around a Forte compiler bug that will soon be fixed, I agree that the #ifdef should not be there. One alternative suggestion: a comment above the offending line(s) of code saying something like "the following section of code causes Forte 6.1 to break; fix your compiler by getting patch blah-blah-blah" (as Shirley pointed out in a previous comment.

Chris, Dan and I have just been chatting. I've added you to this bug because we would like your opinion on the best thing to do here. On the one hand we (Sun) would like to "just compile" Mozilla with our Forte 6 Update 1 compilers (plus patch), and get all the functionality we require (ie. the stuff that is currently #ifdef'ed out), without having to have to apply a special patch to this file to remove the #ifdef. In other words, we would now like the #ifdef removed. On the other hand, the functionality that is currently being #ifdef'ed out, is very trivial, and if the #ifdef's were removed, then the build would break on Solaris for anybody using the F6U1 Sun compilers who hadn't applied the requisite patch.

My thought is that applying the patch would help in a long run. You never know when you will hit the same problem again. By the way, the compiler which Dan is using right now already has a patch: sheep 235 > CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-01 2001/01/31

I agree; if this patch fixes a problem with the compiler that we've exposed with our code, then we should make that patch a requirement to build mozilla. If we've exposed it once, we're more than guaranteed to expose it again (given our track record of copy-n-paste). This shouldn't be any different than the WS5 case where we already have several patches that need to be applied (see http://www.mozilla.org/unix/solaris-build.html )

Thanks Chris. Dan, can we reopen this bug, remove the #ifdef and get that Patches section on http://www.mozilla.org/unix/solaris-build.html updated to include in 109508-03 (sparc) & 109509-03 (intel)?

If someone is going the update the Patches section on http://www.mozilla.org/unix/solaris-build.html , it should actually reflect the following patches are needed when using Sun Workshop 6 Update 1: Sparc: 109513-02, 109508-03, 109505-04 Intel: 109514-02, 109509-03, 109502-02

richb: ok, reopening. However, Netscape management is in a mode where they don't want Netscape employees working on non-critical bugfixes, so I can't really spend any time on it in the near future. If, however, you or someone else wants to take this bug and attach a patch, I'll certainly review it. shirley: I think Ed Burns or someone he's working with owns that web page now. Ed?

Thanks Dan. I've attached a patch to remove the #if/#endif statements, and adjust the comment to point people in the right direction if they get compiler problems on Solaris with Forte in this area. George, we need to get information on the full set of patches for Forte 6 U1 onto http://www.mozilla.org/unix/solaris-build.html , Shirley supplied this info, ie: The following patches are needed when using Sun Workshop 6 Update 1: Sparc: 109513-02, 109508-03, 109505-04 Intel: 109514-02, 109509-03, 109502-02 Now I know you've totally reworked this html page recently to put in a contents section, so I suggest now is the time to add in this new info, and push that new version of the page onto www.mozilla.org. When that's there, we can start looking for r= and sr=.

Oops. For some reason I thought George was already on the cc: list for this bug. Adding him. George, can you please check out the last few comments and let me know if you're agreeable to updating the solaris-build.html page please.

I'm cool with the change, and by the way, I *love* the new layout of the solaris-build.html page. Whoever designed that is brilliant! :-) So, who's got the action item to actually update that page? Dan? Me? Who?

You get to update the new web page George. As we "own" this, you shouldn't need r=/sr= approval (somebody correct me if I'm wrong). Thanks.

r/sr isn't really used for the web pages. r=dmose@netscape.com for the patch. In addition to updating the web page, you'll want to post to .unix and .builds warning people of the new build requirement in advance....

Okay, I've updated the page with the patch numbers for Forte 6 U 1 compilers for SPARC and Intel. gila.mozilla.org should push soon (tonight).

sr=alecf on the latest patch

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

drapeau@eng.sun.com: 1. Wanna add http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/xprod-WorkShop&nav=pub-patches as direct link to the workshop patches ? 2. Could you please add Sun Workshop 6 Update 2 EA (http://access1.sun.com/fortedevprod/) to that page (yes, I know, EA product. BAD... but it compiles Mozilla5), too.... ?

Done. Should push to mozilla.org site in the next couple of hours.

drapeau@eng.sun.com: More items for the Workshop FAQ: - Q: How can I check which (Workshop) patches are already installed on my system ? A: % showrev -p # lists all patches installed on your system. Use grep/egrep to filter that list. "SUNWspro" is the workshop package, therefore % showrev -p | fgrep SUNWspro # should list all Workshop patches - Q: How can I check the Workshop version ? A: % cc -V # lists the version of the C compiler % CC -V # lists the version of the C++-compiler

workaround has been removed.

verified. thanks all.