20297 - xptcall vtable lossage on solaris WS5

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

When using Solaris Workshop 5, configure.in needs to either automatically use
the "-compat=4" switch or else automatically use the SUNW xptcall code.

The WorkShop 5.0 vtable format is different than the Workshop 4.2 version.  The
4.2 version is also the same vtable format as GCC 2.7.2.3.  I don't know what
sort of vtable format the latest (egcs-based) GCC's use.  Does anyone know?

One of the Mozilla goals here is that people should be able to build plugins or
components with a freely available compiler that works with generically built
binaries, and that effects our decision here.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

From the CVS log of configure.in:

> revision 1.25
> date: 1999/08/09 21:07:57;  author: rogerl%netscape.com;
>
> Backing away from SUNW 5.0 version - the 4.2 workshop is the same as GCC
> output and Matthias has a way to get the 5.0 workshop to produce 4.2 (and
> hence GCC) compatible vtables. I'm leaving the structure intact for now in
> case we need to use it for flag setting or whatever.

I've added rogerl and a few other folks who might have some insight or interest
to the CC list of this bug.  I was going to add Matthias Spycher (sp?) as well,
since Roger metioned him in the Changelog, but he doesn't appear to have a
bugzilla account.

Comments, anyone?

It would also be interesting to know whether the WorkShop 6 compiler still
supports the -compat=4 flag, as well as what its native vtable format is.

Comment 2

[Akhil Arora]

Matthias has since left Sun. I will try and find out more about workshop6 and
its vtable layout.

Comment 3

[Akhil Arora]

Found out that currently there are no plans to stop supporting the -compat=4
option. Note that this option exists for compatibility with version 4 of the
compiler, and just happens to also work with gcc/egcs. The compiler group
recommends that we fix our code so that we do not depend upon the vtable layout.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Someone (tor, I think) said that even with the same vtable format, 4.2 and gcc
do different name-mangling.  Does this then mean that plugin compatibility is
impossible anyway?

Now, as I understand it, the reason the vtable format had to change between
workshop 4.2 and 5.0 is that the old vtable format was inadequate for
implementing the current ANSI C++ spec.  This means that if gcc wants to stay
with the standard, they'll need to get a new vtable format as well.  If we're
lucky, they will have chosen the same format as 5.0.  It would be interesting to
know what the latest egcs/gcc does use, and if it's format has actually changed. 

Comment 5

[tor]

Attachment: autoconf stuff for solaris xptcall selection

Comment 6

[tor]

I have seen a few people attempt to compile mozilla with SUNWspro5.0 without
the -compat=4 flag and get burned because the xptcall makefile unconditially
includes the gcc assembly.  The attached patch makes changes to autoconf to
check what style vtables are being used by ${CXX} and selects the appropriate
code to compile.  This patch has been tested with the following values of CXX:

	g++ (egcs-1.1)
	/opt/SUNWspro4.2/bin/CC
	/opt/SUNWspro5.0/bin/CC -compat=4
	/opt/SUNWspro5.0/bin/CC

Could someone please review the patch and give a go/no-go for checkin?

Comment 7

[tor]

Attachment: updated autoconf patch for solaris xptcall code selection

Comment 8

[tor]

Updated patch to only use the -library=iostream workaround when needed
(SUNWspro5.0 in non-compat=4 mode).

Comment 9

[Scott Collins]

This is good.  We definitely want to ensure that people can build the product 
with whatever their compiler of choice is ... where that's possible.  We _always_ 
want to make sure that we can be built with the leading freely available 
compilers.  In particular, outside developers must be able to use any reasonable 
compiler to build plugins or components that work with our binaries built with 
_our_ choice of compiler.  Only this will ensure a good binary distribution model 
for 3rd party components.

Comment 10

[tor]

Attachment: Updated patch for vtable autodetect

Comment 11

[tor]

Updated patch that switches control variable to SUNWSPRO5_VTABLE and grabs
the appropriate C++ libraries for the Workshop5.0 compilers.

Comment 12

[tor]

Forgot to mention - tested on gcc-2.95.1, SUNWspro4.2, and SUNWspro5.0 (with
and without -compat=4).

Comment 13

[Margaret Chan]

I have successfully built M13 with the 02/09/00 patch using Workshop 5.0 without 
the option -compat=4.

Comment 14

[Jon Granrose]

cls gave the patch(es) for this bug his r=cls seal of approval via email, so 
this is good to check in once the tree opens this afternoon.

Comment 15

[tor]

Patch checked in.

Comment 16

[tor]

wensleydale (gcc) and nebiros (SUNWspro5.0) are happy (green) with the patch,
as is my usual SUNWspro4.2 build tree.  Closing bug.

Comment 17

[Jon Granrose]

yeah, baby!

Comment 18

[drapeau]

You are The Man (tm)!

Comment 19

[Jon Granrose]

*** Bug 24922 has been marked as a duplicate of this bug. ***

Comment 20

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/cec86a22e7c5
[fenix] For https://github.com/mozilla-mobile/fenix/issues/20297: close tab to avoid saving the same tab to collection