All users were logged out of Bugzilla on October 13th, 2018

xptcall vtable lossage on solaris WS5

RESOLVED FIXED in M14

Status

P3
normal
RESOLVED FIXED
19 years ago
14 years ago

People

(Reporter: dmose, Assigned: dmose)

Tracking

Trunk
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

19 years ago
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.
(Assignee)

Comment 1

19 years ago
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

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

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
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. 
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 5

19 years ago
Created attachment 4681 [details] [diff] [review]
autoconf stuff for solaris xptcall selection

Comment 6

19 years ago
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?
Keywords: patch

Comment 7

19 years ago
Created attachment 4685 [details] [diff] [review]
updated autoconf patch for solaris xptcall code selection

Comment 8

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

Comment 9

19 years ago
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

19 years ago
Created attachment 5120 [details] [diff] [review]
Updated patch for vtable autodetect

Comment 11

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

Comment 12

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

Comment 13

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

Updated

19 years ago
Target Milestone: M14

Comment 14

19 years ago
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

19 years ago
Patch checked in.

Comment 16

19 years ago
wensleydale (gcc) and nebiros (SUNWspro5.0) are happy (green) with the patch,
as is my usual SUNWspro4.2 build tree.  Closing bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 17

19 years ago
yeah, baby!

Comment 18

19 years ago
You are The Man (tm)!

Comment 19

19 years ago
*** 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.