Closed Bug 838 Opened 26 years ago Closed 25 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: 25 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.