33739 - FreeBSD 4.0 build crashes at startup

Status: RESOLVED DUPLICATE of bug 39268

(Core :: XPCOM, defect, P3)

Description

[Arun Sharma]

From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (X11; I; Linux 2.2.12-20 i686)
BuildID:    2000070614

FreeBSD 4.0 ships with gcc 2.95.x which uses CFRONT_STYLE_THIS_ADJUST
and not THUNK_BASED_THIS_ADJUST. Changing this in

xpcom/reflect/xptcall/src/md/unix/xptc_platforms_unixish_x86.h

will fix the problem.


Reproducible: Always
Steps to Reproduce:
1. Build on FreeBSD 4.0 with gcc 2.95.x 
2. Start the browser
3.

Comment 1

[Suresh Duddi (gone)]

Sound like an ok thing to do.

Comment 2

[Mike McCabe]

Reassigning to jband, xptcall owner.

Comment 3

[John Bandhauer]

Reasigning to shaver. He still owns the issue of how and to what extent we are 
going to achieve binary compatibility of components within and across 'nix 
platforms where that is possible. Sometimes the answer is to set compiler flags 
to force the compiler to build with a certain calling convention rather than 
change xptcall to expect a calling convention specialized by the default 
settings of the compiler.
news://news.mozilla.org/3781ADE7.7762F69C%40netscape.com

Comment 4

[leger]

Adding crash keyword.

Comment 5

[Gervase Markham [:gerv]]

Confirming this to pop it into shaver's radar (like, he needs more bugs ;-)

Gerv

Comment 6

[Jonathan Lennox]

The same thing happens on FreeBSD 3.4 if you build with gcc 2.95.2 (the gcc295 

package) rather than the system-shipped gcc 2.7.2.3.  Backing out the FreeBSD 

part of the revision 1.6 change to xptc_platforms_unixish_x86.h fixes this.



Changing the #defines in xptc_platforms_unixish_x86.h to behave differently on 

FreeBSD 3.4 based on the values of __GNUC__ and __GNUC_MINOR__ would be 

possible, but I don't know what you're trying to do with regard to binary 

compatibility.



I'm not sure if there's a way to force binary compatibility with 2.7.2.3;

-fvtable-thunks might do it, but according to the gcc 2.95.2 info file, you have 

to recompile all the g++ support libraries to use it.



Is there a Right Thing to do for situations like this?

Comment 7

[Mike Shaver (:shaver emeritus)]

If there are binary incompatibilities in the compiler versions, then I think we
just end up having to borrow some of FreeBSD's trouble.

Maybe vendors will need to ship two versions for FreeBSD, though that seems like
a great way to get off of a vendor's platform list.  Is there someone in the
FreeBSD community that can educate me as to how other programs handle this? 
From the comment above about needing to recompile all of the g++ support
libraries, I would imagine that we're not alone here.

Comment 8

[Christopher Blizzard (:blizzard)]

Sounds like the longest /usr/ports build.  Ever.

Comment 9

[Markus Doehr]

Yesterday I checked out the FreeBSD-Stable-4.0-Tree and now under /usr/contrib
there exists a gcc295 directory.

They seem to switch to gcc-2.95 as default compiler. There are currently
problems building world (aka building everything new) so I'll give more
information as soon as I checked again.

Comment 10

[Eric Hodel]

Works for me
FreeBSD -current
GCC 2.95
7/23 CVS pull

Comment 11

[markush]

Works out of the box with Mozilla pulled from CVS 2000-08-13 and FreeBSD
4.1-STABLE.

Comment 12

[leger]

Updating QA Contact

Comment 13

[Jonathan Lennox]

See the comments I just added to bug 39268.  I believe I untangled the whole
FreeBSD object-layout mess...

Comment 14

[Mike Shaver (:shaver emeritus)]

You might be right: can someone here test that patch on FreeBSD4.0?  I still
hate the two-layouts problem, but there really aren't many ways around it.

Comment 15

[Jonathan Lennox]

I don't think the two-layouts thing is really a problem per se.  The "official"
object layout for FreeBSD should always be the one which /usr/bin/g++ produces. 
Support for /usr/local/bin/g++295 on 3.x systems is easy to do in the source
tree, since it uses the same object layout as Linux, but since it requires
jumping through some hoops to accomplish it (setting CC and CXX at
configure-time) it'll likely always be a developers-only trick.

Comment 16

[Mike Shaver (:shaver emeritus)]

I'm marking this as a dup of 39268, because I think Jonathan's patch there will
save the day.


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