156794 - OpenVMS needs COMPAQ_CXX defining in configure

Status: VERIFIED DUPLICATE of bug 149032

(SeaMonkey :: Build Config, defect)

Description

[Colin Blake]

The changes made for bug 149032 (the introduction of CPP_THROW_NEW) upset the
OpenVMS build. Since we share compilers with the Tru64 folks, the easiest way to
fix this is to define COMPAQ_CXX in the OpenVMS section of configure. Will
attach a patch next.

Comment 1

[Colin Blake]

Attachment: Fix OpenVMS build breakage

Chris, who can review and super-review this?

Comment 2

[hacker formerly known as [e-mail]]

Actually, that variable is going away to be replaced by an autoconf test.  The
patch is in bug 149032.

Comment 3

[Colin Blake]

Hmm, how about changing the patch in bug 149032 so that in the OpenVMS section
it defines _OPENVMS_CXX (instead of COMPAQ_CXX which I defined in my patch) and
then add:

-a -z "$_OPENVMS_CXX"

to the new line:

if test -z "$_MOZ_CPP_EXCEPTIONS" -a -z "$VACPP" -a -z "$_WIN32_MSVC"

Comment 4

[hacker formerly known as [e-mail]]

Because I'm trying to get rid of the _CXX altogether.  We still have the VACPP
exception because even though it should pass the test, there's a compiler bug
that causes it to miscompile in optimized builds.  Afaik, the test doesn't
catcht hat, though I should get mkaply to verify that.  WIN32_MSVC is special
caesd because we don't do any feature tests for MSVC (carryover from the nmake
build) and it was failing that test due to it interpretting a .C file as a .c
file instead of a .cpp file.  

Comment 5

[Colin Blake]

Yeah well the configure test works in OpenVMS but a compiler bug prevents the
code from actually doing the right thing. Its fixed in later versions of the
compiler but for other reasons I don't want to upgrade my build system right now.

We'll be able to take the hack out one day. Promise!!

Comment 6

[hacker formerly known as [e-mail]]

Argh. This is becoming far more complicated that it needed to be.  Is there a
way to test for the bug that you are seeing?  The only way I seeing the hack
going away is if we mandate that compilers support this particular feature in
order to build mozilla.  Since I don't ever see that mandate coming to pass, the
hack will probably remain indefinitely.  Anyway, I'm duping this to 149032
rather than having 2 bugs to cover the same subject.


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

Comment 7

[Jon Granrose]

v dup.