Closed Bug 739 Opened 27 years ago Closed 26 years ago

HP-UX's cfront C++ ("CC") can't build 4th September 1998 Mozilla

Categories

(SeaMonkey :: Build Config, defect, P2)

SGI
HP-UX
defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: rkl, Assigned: briano)

Details

28th July 1998 release of Mozilla built with HP's cfront C++ ("CC" command) with only minor changes. 4th September 1998 release of Mozilla has major, major problems building with "CC" on HP-UX 9.X or 10.X (I suspect this may well apply to all cfront-based C++'s, not just HP's). The list of files that gave me "aggro" (and this is up until I got really fred up, there may be more) are: Filename Problem base/src/nsAtomTable.cpp "new" operator params not treated properly build/build_number Constant too large ("L" on end might fix it) cmd/winfe/mozilla.cpp, xpcom/src/nsRepository.cpp, xpcom/tests/TestFactory.cpp, xpcom/tests/TestServMgr.cpp and xpcom/tests/dynamic/TestDynamic.cpp RegisterFactory() overload js/ref/os/hpux.h and nsprpub/pr/include/md/_hpux.cfg HAVE_LONG_LONG was originally undefined, probably because CC doesn't support long long's. Really it should be defined (HP's ANSI C and ANSI C++ both support long long, as does gcc/g++). Causes rippling problems in other sources files if not defined. modules/oji/public/nsIJVMManager.h NS_JVM_ERROR_BASE RHS constant is too large (perhaps cast to int ?) modules/oji/public/nsIJVMPlugin.h and modules/oji/src/jvmmgr.cpp GetPluginInstance() overload nsprpub/pr/include/prtypes.h CC doesn't support signed typedefs, so generates a (very frequently displayed) warning... nsHashtable.h CC-compiled code won't link - nsHashKey::nsHashKey code not visible For the moment, I'm switching to gcc/g++, but also will have a look at HP's ANSI C and HP's ANSI C++ ("aCC") in combo to see they work.
Status: NEW → ASSIGNED
Copying wtc and scullin, for their input.
The warning caused by 'signed char' in nsprpub/pr/include/prtypes.h will be fixed in the next nspr release. As for HAVE_LONG_LONG in nsprpub/pr/include/md/_hpux.cfg, the Mozilla code needs to compile whether it is defined or not. All operations on PRInt64/PRUint64 variables must use the LL macros defined in nsprpub/pr/include/prlong.h. Suppose this is indeed the problem, we need to fix the code to use the LL macros, otherwise it won't compile on platforms without 64-bit integer suppoort. On the other hand, in the next nspr release, HAVE_LONG_LONG will be defined for HP-UX.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Old bug, old codebase. Marking won't fix. Re-open if I am incorrect.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.