Closed Bug 20297 Opened 25 years ago Closed 25 years ago

xptcall vtable lossage on solaris WS5


(SeaMonkey :: Build Config, defect, P3)



(Not tracked)



(Reporter: dmosedale, Assigned: dmosedale)




(3 files)

When using Solaris Workshop 5, 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  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.
From the CVS log of

> revision 1.25
> date: 1999/08/09 21:07:57;  author:;
> 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.
Matthias has since left Sun. I will try and find out more about workshop6 and
its vtable layout.
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.
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. 
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/SUNWspro5.0/bin/CC -compat=4

Could someone please review the patch and give a go/no-go for checkin?
Keywords: patch
Updated patch to only use the -library=iostream workaround when needed
(SUNWspro5.0 in non-compat=4 mode).
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.
Updated patch that switches control variable to SUNWSPRO5_VTABLE and grabs
the appropriate C++ libraries for the Workshop5.0 compilers.
Forgot to mention - tested on gcc-2.95.1, SUNWspro4.2, and SUNWspro5.0 (with
and without -compat=4).
I have successfully built M13 with the 02/09/00 patch using Workshop 5.0 without 
the option -compat=4.
Target Milestone: M14
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.
Patch checked in.

wensleydale (gcc) and nebiros (SUNWspro5.0) are happy (green) with the patch,
as is my usual SUNWspro4.2 build tree.  Closing bug.
Closed: 25 years ago
Resolution: --- → FIXED
yeah, baby!
You are The Man (tm)!
*** Bug 24922 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.