Closed Bug 838 Opened 26 years ago Closed 26 years ago

Mozilla fails to build correctly on any non-gcc/g++ HP-UX compiler

Categories

(SeaMonkey :: Build Config, defect, P2)

SGI
HP-UX
defect

Tracking

(Not tracked)

CLOSED FIXED

People

(Reporter: rkl, Assigned: briano)

Details

Well, I'm back again with my exploits on HP-UX 10.20 and the by-now-surely- infamous 4th September 1998 Mozilla build - here's a progress report: * HP's cfront-based C++ ("CC" command) just can't build 4th Sept 98 Mozilla at all (bombs out early during the compile and many fixes later convinced me to give up). All previous Mozilla releases built fine with "CC", so there's a lot of "g++-isms" been added with the 4th Sept release I suspect. * HP's ANSI C++ ("aCC" command) can actually build Mozilla, but it core dumps during intiialisation. I didn't really fancy debugging this, so I concentrated on installing the latest gcc/libstdc++ and using that to build Mozilla instead. * gcc 2.8.1/libstdc++ 2.8.1.1 both builds Mozilla and manages to run Mozilla on HP-UX 10.20, but there's serious problems with background tiling - loads of graphical corruption on any pages with background tiles. So the advice is to stick with gcc/g++ for building Mozilla on HP-UX - all other compilers don't work. Even gcc/g++ produces that background tile problem though. Has anyone at Netscape actually managed to build the 4th Sept 98 Mozilla at all and get it to work sensibly ? BTW, there's a major omission in the build config for Mozilla - a "mid-way" build - i.e. one without optimisation *or* debugging. I ended up having to hack around in 3 or 4 places to get rid of the -O's (whilst keeping BUILD_OPT defined). I did this to rule out optimisation bugs in gcc/g++ (I ruled them out: same problem with a non-optimised build).
Status: NEW → ASSIGNED
I am working on this. Or rather, I'm working on verification of pieces of this with respect to the systems we have here at Netscape and the versions/updates of the compilers installed on them. More data to come as I slowly dig it up.... [Thanks, Terry (terry@mozilla.org) for pointing out that I hadn't designated this bug as Assigned to me. I thought I had....]
This looks old, can we get some more-recent status?
Setting all current Open Critical and Major to M3
I'm working on getting a publicly viewable Tinderbox build running on HP-UX 10.20, but I still don't know anything about the state of 5.0 on HP-UX, because the build fails in configure. I'm stuck at the moment trying to identify/fix that problem: eggroll:cltbld[275] cc -Ae -o conftest -DMOZ_TOOLKIT=gtk -DMOZ_DLL_SUFFIX=sl -I/builds/tinderbox/SeaMonkey/nspr/include -L/builds/tinderbox/SeaMonkey/nspr/lib conftest.c -lnspr21 -ll -lm -lc_r eggroll:cltbld[276] ./conftest /usr/lib/dld.sl: Call to mmap() failed - TEXT /builds/tinderbox/SeaMonkey/nspr/lib/libnspr21.sl /usr/lib/dld.sl: Permission denied IOT trap (core dumped)
Target Milestone: M3 → M4
moving to m4
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I've had a Tinderbox build on HP-UX 10.20 using the native compiler (cc/aCC) for several weeks now. It still doesn't quite build, but (with help!) it should soon. I'm closing this bug. Please feel free to reopen it or submit a new one if you're not happy about this....
Status: RESOLVED → CLOSED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.