Closed Bug 34553 Opened 25 years ago Closed 25 years ago

Problem compiling under BeOS see include patches for fixes.

Categories

(Core :: XPCOM, defect, P2)

x86
BeOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ykoehler, Assigned: dp)

Details

Attachments

(3 files)

Most problem we're having is due to XP_BEOS missing and a problem with the GNU compiler we have. Please check the attachment and checked in. I'm missing check in permission at the present time.
Priority: P3 → P1
We are frozen for M15 now. I will check it in once the tree opens.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: patch
Priority: P1 → P2
Target Milestone: --- → M16
With the exception of the diffs checking for gcc 2.95+, this patch has been checked in. Given the platform specific nature of the patch and the lack of an alternative (beos5 only comes gcc 2.95+, right?), I'd argue that this change is worth checking in as it has no chance of upsetting the stability of M15 for the tier 1 platforms.
Well the reason for the diff in regards to the GNU stuff is because Fred Fish (owner of GNU stuff?) did fix a COMPILER bug which was causing that to failed compiling. So it's not platform specific but Compiler specific, I've enclosed that inside BEOS just to get the fix approve faster ;-)
That's strange because I've been using gcc 2.95.2 under linux since it was released and I haven't run across that particular bug. *shrug*
And you did compile with the DEBUG define ? as this part of code is also inside a #ifdef DEBUG. I have to admit that I didn't "create" that patch but still it surprise me as the person who did, Fred Fish, should know is stuff anyway I don't care until it compile over here...
Yes, the default build is DEBUG. And the patch appears to be wrong. It makes it so that nsString.h is only defined if you're compiling under beos with gcc 2.95+ when what you really want to do is comment out that bit of broken code for beos only. It doesn't even get to the compiler error on my beos 5.0 box. Try this one instead. Index: xpcom/components/xcDll.cpp =================================================================== RCS file: /cvsroot/mozilla/xpcom/components/xcDll.cpp,v retrieving revision 1.39 diff -u -r1.39 xcDll.cpp --- xcDll.cpp 2000/03/25 08:54:22 1.39 +++ xcDll.cpp 2000/04/10 17:32:38 @@ -449,6 +449,7 @@ void nsDll::BreakAfterLoad(const char *nsprPath) { +#ifndef XP_BEOS #ifdef DEBUG static PRBool firstTime = PR_TRUE; static nsCString breakList[16]; @@ -496,5 +497,6 @@ #endif } #endif /* DEBUG */ +#endif /* !XP_BEOS */ return; }
Attached patch BeOS fixes for the entire tree (deleted) — Splinter Review
The attached patch includes the one I pasted below and enables me to get a full BeOS compile on my BeOS 5.0 box. Still shooting to get this change in before we release M15.
The tree has branched for M15 and the 2nd attachment has been check into the tree on the tip. I'll see about getting it in the M15 tarball as well.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
cls@seawood.org : Thanks for fixing this.
the M15 branch is ready for porting fixes.
The changes are in and working!
Status: RESOLVED → VERIFIED
the patch i just attached fixes a bug introduced by the second attachment ("BeOS fixes for the entire tree") - nsGfxFactoryBeOS::CreateInstance() was creating an nsDeviceContextBeOS object where it should have been creating an nsRenderingContextBeOS object
Justin, are you sure this last patch apply to this BUG ?
i figured that the last patch applies to this bug because: * it fixes a problem introduced by the second patch * the bug isn't marked CLOSED yet, (and yannick, not the QA person, changed its status to VERIFIED :) so it's still fair game if you agree, yannick, you could reopen the bug. if not, let me know, and i'll make a new bugzilla entry for the patch...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: