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)
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.
Assignee | ||
Updated•27 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•27 years ago
|
||
Copying wtc and scullin, for their input.
Comment 2•27 years ago
|
||
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.
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 3•26 years ago
|
||
Old bug, old codebase. Marking won't fix. Re-open if I am incorrect.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•