Closed
Bug 20860
Opened 25 years ago
Closed 15 years ago
Check if the build config is ready for sparcv9 (64bit sparc)...
Categories
(SeaMonkey :: Build Config, defect, P4)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: roland.mainz, Unassigned)
References
Details
(Keywords: 64bit)
Attachments
(7 files)
|
84.16 KB,
patch
|
Details | Diff | Splinter Review | |
|
84.96 KB,
patch
|
Details | Diff | Splinter Review | |
|
89.12 KB,
patch
|
Details | Diff | Splinter Review | |
|
85.74 KB,
patch
|
Details | Diff | Splinter Review | |
|
988 bytes,
patch
|
Details | Diff | Splinter Review | |
|
85.39 KB,
patch
|
Details | Diff | Splinter Review | |
|
3.89 KB,
patch
|
Details | Diff | Splinter Review |
I'd like to create a sparcv9 (64bit sparc) build of Mozilla to check whether Mozilla is a 64bit clean application (and the neccesary cleanup will wipe-out some bugs, too), but this requires some changes in the build system: 1. Solaris 2.7/2.8 can run both 32bit and 64bit apps., therefore the shared libraries can't be stored in /usr/lib for both 32bit and 64bit. 32bit libs are stored in /usr/lib/ (as usual), their 64bit euqivalents are stored in /usr/lib/sparcv9/. The build system needs to be enhanced to create sparcv9/ subdirs for all mozilla shared libs and plugins should be searched in plugins/sparcv9/ and not plugins/. 2. LD_LIBRARY_PATH has a 64bit twin: LD_LIBRARY_PATH_64 and so on (IMHO we'll find more issues during porting...)...
|
||
Comment 1•25 years ago
|
||
I don't know a thing about 64 bit sparc so I'm reassigning back to Roland. Added self and briano to the cc list for his input.
Assignee: granrose → Roland.Mainz
Target Milestone: M15
|
Reporter | |
Comment 2•25 years ago
|
||
64bit sparc code (Sun calls this sparcv9-code, older sparcs used sparcv7/sparcv8 code) isn't very problemtic. short=16bit, int=32bit, long=64bit, long long=64bit -- snip -- /* datatype size test * written by Roland.Mainz@informatik.med.uni-giessen.de * gcc longlonglength.c * OR * cc longlonglength.c * OR * cc -xarch=v9 longlonglength.c */ #include <stdlib.h> #include <stdio.h> int main( void ) { #define PRINT_SIZE(x) printf( "> " #x "=%d\n", (int)sizeof( x ) ) PRINT_SIZE(short); PRINT_SIZE(int); PRINT_SIZE(long); PRINT_SIZE(long long); PRINT_SIZE(size_t); exit( EXIT_SUCCESS ); } -- snip -- returns: -- snip -- % cc -xarch=v9 longlonglength.c % ./a.out > short=2 > int=4 > long=8 > long long=8 > size_t=8 -- snip -- sparcv9 shouldn't be diferent that sparc - except that there a bugs which should be fixed or if mozilla contains asm code or a code generator. The main reason of sparcv9 Mozilla is to squish all 64bit-related bugs. Known problems with sparcv9 build: - gcc isn't sparcv9-ready yet, gcc bootstrap fails (nsinstall cores) - gdb isn't sparcv9-ready yet (no gdb without gcc, and no gcc without gdb - the development teams are crazy ;-( ) - Mozilla 5 doesn't compile with Sun Workshop 5/6 due compilation errors (mainly syntax problems with CC (c++)) - ./mozilla startup wrapper script uses LD_LIBRARY_PATH instead of LD_LIBRARY_PATH_64 (LD_LIBRARY_PATH_64 is for 64bit apps., LD_LIBRARY_PATH is for 32bit apps. - Solaris 2.7/2.8 is a mixed 32/64bit OS) * My first posting contains the issue /usr/lib vs. /usr/lib/sparcv9 The following shows how I set-up Mozilla to get a sparcv9 build (this assumes that there are sparcv9 builds of glib/GTK+/libIDL): -- snip -- mkdir objdir cd objdir export LD_LIBRARY_PATH_64=~/libsparcv9/lib export PATH=~/libsparcv9/bin:$PATH; export CC="/opt/SUNWspro/bin/cc -xarch=v9" ; export CXX="/opt/SUNWspro/bin/CC -xarch=v9" ../configure --x-includes=/usr/dt/include --x-libraries=/usr/dt/lib/sparcv9 --enable-x11-shm --enable-optimize --disable-debug -- snip -- Last but not least: Can someone FIX the Motif part (I have some Motif sparcv9 libs with debugging code here which may be very usefull, but Motif is broken in Mozilla), please ?
|
|
Reporter | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
Reporter | |
Comment 3•25 years ago
|
||
Accepting bug... but I have a bunch of problem: - Who is responsive/who maintains the configure script ? - is there anyone briano/grandrose who has a Solaris 2.7 UltraSPARC machine who can help me a little bit ?
|
|
Reporter | |
Comment 4•25 years ago
|
||
Briano, Granrose ? Can you help me a little bit ? 1st problem on my list is that Mozilla source can't be compiled with Sun Workshop compilers (e.g. Sun vendor compiler). Are there any cc/CC options I'm missing ?
|
||
Comment 5•25 years ago
|
||
Not that I know of. I'm having the same problem with my Workshop (4.2 and 5.0) Solaris Tinderbox builds. I can build everything successfully, but the binaries won't run. I don't know how to fix this. I keep hoping one of the Sun alliance guys will help me with this....
|
|
Reporter | |
Comment 6•25 years ago
|
||
Briano, please tell me how you can compile Mozilla with Sun Workshop. I never managed it to get the 1st C++-Source compiled ;-( Are there any configure options ?
|
|
||
Comment 7•25 years ago
|
||
I don't do anything special. I do this (using sh): export PATH="/tools/workshop-5.0/bin:$PATH" export LD_LIBRARY_PATH="/tools/workshop-5.0/lib:/usr/local/lib" export CC="cc" export CXX="CC" and then I configure like normal (I use --disable-tests, because I don't have enough disk space to build the test binaries also). I've added Wan-Teh to the cc: list because I think he would be interested in this.
|
|
Reporter | |
Comment 8•25 years ago
|
||
I can't get the build working, M12 failed, and the source snaphot from 12.1.2000 failed, too due different cc/CC errors (Sun Workshop 6EA) ;-( M12 failure: -- snip -- cc -xstrconst -o SunOS5.7_sparc_32_PTH_DBG.OBJ/plvrsion.o -c -g -KPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__ -DSOLARIS -D_PR_HAVE_OFF64_T -D_REENTRANT -DHAVE_POINTER_LOCALTIME_R -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -DXP_UNIX -DDEBUG -UNDEBUG -DDEBUG_gisburn -I/home/gisburn/package-builds/mozilla5/M12/mozilla/objdir/dist/include -ISunOS5.7_sparc_32_PTH_DBG.OBJ plvrsion.c CC -Qoption cg -xstrconst -o SunOS5.7_sparc_32_PTH_DBG.OBJ/prstrms.o -c -g -KPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__ -DSOLARIS -D_PR_HAVE_OFF64_T -D_REENTRANT -DHAVE_POINTER_LOCALTIME_R -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -DXP_UNIX -DDEBUG -UNDEBUG -DDEBUG_gisburn -I/home/gisburn/package-builds/mozilla5/M12/mozilla/objdir/dist/include prstrms.cpp "prstrms.h", line 55: Error: streampos is not defined. "prstrms.h", line 55: Error: streamoff is not defined. "prstrms.h", line 67: Warning: PRfilebuf::setbuf hides the virtual function std::basic_streambuf<char, std::char_traits<char>>::setbuf(char*, long). "prstrms.cpp", line 100: Error: The function "base" must have a prototype. "prstrms.cpp", line 100: Error: Pointer type needed instead of int. "prstrms.cpp", line 149: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 149: Error: The function "ebuf" must have a prototype. "prstrms.cpp", line 152: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 155: Error: setb is not a member of std::basic_streambuf<char, std::char_traits<char>>. "prstrms.cpp", line 178: Error: The function "allocate" must have a prototype. "prstrms.cpp", line 183: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 184: Error: The function "base" must have a prototype. "prstrms.cpp", line 184: Error: The function "ebuf" must have a prototype. "prstrms.cpp", line 187: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 206: Error: The function "allocate" must have a prototype. "prstrms.cpp", line 211: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 218: Error: The function "base" must have a prototype. "prstrms.cpp", line 218: Error: The function "blen" must have a prototype. "prstrms.cpp", line 220: Error: The function "base" must have a prototype. "prstrms.cpp", line 220: Error: The function "base" must have a prototype. "prstrms.cpp", line 220: Error: The function "base" must have a prototype. "prstrms.cpp", line 227: Error: The function "ebuf" must have a prototype. "prstrms.cpp", line 230: Error: The function "unbuffered" must have a prototype. "prstrms.cpp", line 232: Error: The function "setb" must have a prototype. "prstrms.cpp", line 236: Error: streampos is not defined. "prstrms.cpp", line 237: Error: streamoff is not defined. Compilation aborted, too many Error messages. make[3]: *** [SunOS5.7_sparc_32_PTH_DBG.OBJ/prstrms.o] Error 1 make[3]: Leaving directory `/home/gisburn/package-builds/mozilla5/M12/mozilla/nsprpub/lib/prstreams' make[2]: *** [export] Error 2 make[2]: Leaving directory `/home/gisburn/package-builds/mozilla5/M12/mozilla/nsprpub/lib' make[1]: *** [export] Error 2 make[1]: Leaving directory `/home/gisburn/package-builds/mozilla5/M12/mozilla/nsprpub' make: *** [export] Error 2 -- snip -- 12.1.2000 snsapshot build failure: -- snip -- /opt/SUNWspro/bin/CC -o nsElementTable.o -c -mt -g -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_IPC_H=1 -DHAVE_SYS_SHM_H=1 -DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBRESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_USING=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DDEBUG=1 -DDEBUG_gisburn=1 -DTRACING=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 -DOSTYPE=\"SunOS5\" -DOJI -D_IMPL_NS_HTMLPARS -DXML_DTD -I../../dist/include -I../../../include -I../../dist/include -I../../dist/include -I../../dist/include -I. -I/usr/openwin/include -KPIC ../../../htmlparser/src/nsElementTable.cpp /opt/SUNWspro/bin/CC -o CNavDTD.o -c -mt -g -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_IPC_H=1 -DHAVE_SYS_SHM_H=1 -DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBRESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_USING=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DDEBUG=1 -DDEBUG_gisburn=1 -DTRACING=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 -DOSTYPE=\"SunOS5\" -DOJI -D_IMPL_NS_HTMLPARS -DXML_DTD -I../../dist/include -I../../../include -I../../dist/include -I../../dist/include -I../../dist/include -I. -I/usr/openwin/include -KPIC ../../../htmlparser/src/CNavDTD.cpp "../../dist/include/nsCOMPtr.h", line 605: Warning (Anachronism): Old explicit specialization syntax. "../../dist/include/nsCOMPtr.h", line 848: Warning (Anachronism): Old explicit specialization syntax. "../../dist/include/nsFileStream.h", line 146: Error: A typedef name cannot be used in an elaborated type specifier.. "../../dist/include/nsFileStream.h", line 147: Error: A typedef name cannot be used in an elaborated type specifier.. "../../../htmlparser/src/CNavDTD.cpp", line 67: Warning: String literal converted to char* in initialization. 2 Error(s) and 3 Warning(s) detected. make[2]: *** [CNavDTD.o] Error 2 make[2]: Leaving directory `/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/htmlparser/src' make[1]: *** [libs] Error 2 make[1]: Leaving directory `/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/htmlparser' make: *** [libs] Error 2 -- snip --
|
|
Reporter | |
Comment 9•25 years ago
|
||
What about careting a new bug on which this one depends on ? Title: Can't compile&&run Mozilla with Sun Workshop 4/5/6EA... ?
|
||
Comment 10•25 years ago
|
||
The easiest workaround for the first build problem
(in mozilla/nsprpub/lib/prstreams) is to remove
DIRS += prstreams
from mozilla/nsprpub/lib/Makefile. Mozilla does
not use that library, so it is okay to skip it.
What is the output of 'CC -V'? The cause of that
problem is that mozilla/nsprpub/lib/prstreams/Makefile
tests for the hardcoded Workshop version number 5.0.
So another workaround is to change "5.0" to "6EA" in
mozilla/nsprpub/lib/prstreams/Makefile.|
|
Reporter | |
Comment 11•25 years ago
|
||
Output of CC -V is:
-- snip --
% CC -V
CC: Sun WorkShop 6 1999/11/09 C++ 5.1 Dev
-- snip --
I changed mozilla/nsprpub/lib/prstreams/Makefile.in to match "Workshop" instead
of "5.0". This should cover Sun Workshop 6, 7, 8 and 819 as well =:-)
-- snip --
else
# The C++ compiler in Workshop 5.0 uses standard
# iostreams as default. -library=iostream will
# allow Workshop 5.0 to work with classic iostreams.
ifndef NS_USE_GCC
CCC_VERSION := $(shell $(CCC) -V 2>&1)
ifneq (,$(findstring Workshop,$(CCC_VERSION)))
CCC_ONLY_FLAGS += -library=iostream
endif
endif
endif
-- snip --
----
Next build problem was:
-- snip --
make[2]: Entering directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/caps/src'
/opt/SUNWspro/bin/CC -o nsBasePrincipal.o -c -mt -g -DMOZILLA_CLIENT
-DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino
-DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1
-DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1
-DHAVE_UINT16_T=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_IPC_H=1 -DHAVE_SYS_SHM_H=1
-DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1
-DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1
-DHAVE_LIBRESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1
-DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1
-DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1
-DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1
-DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1
-DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1
-DHAVE_CPP_USING=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_I18N_LC_MESSAGES=1
-DMOZ_MAIL_NEWS=1 -DDEBUG=1 -DDEBUG_gisburn=1 -DTRACING=1
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1
-DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 -DOSTYPE=\"SunOS5\" -DOJI
-I../../dist/include -I../../../include -I../../dist/include
-I../../dist/include -I../../dist/include -I../../../include
-I../../../caps/src/../include -I/usr/openwin/include -KPIC
../../../caps/src/nsBasePrincipal.cpp
"../../dist/include/nsISupportsUtils.h", line 856: Warning (Anachronism): Old
explicit specialization syntax.
"../../../caps/src/nsBasePrincipal.cpp", line 172: Error: Cannot cast from void*
to char.
1 Error(s) and 1 Warning(s) detected.
make[2]: *** [nsBasePrincipal.o] Error 1
make[2]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/caps/src'
make[1]: *** [libs] Error 2
make[1]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/caps'
make: *** [libs] Error 2
-- snip --
I hacked caps/src/nsBasePrincipal.cpp to get rid of this problem (e.g. trying to
dereference a void * ptr ;-( ):
-- snip --
PR_STATIC_CALLBACK(PRBool)
AppendCapability(nsHashKey *aKey, void* aData, void* aStr)
{
nsAutoString name( ((nsStringKey*)aKey)->GetString() );
char value = *((char *)aData) + '0';
nsString* capStr = (nsString*)aStr;
-- snip --
----
Next problem is:
-- snip --
/opt/SUNWspro/bin/CC -o CNavDTD.o -c -mt -g -DMOZILLA_CLIENT -DBROKEN_QSORT=1
-DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino
-DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1
-DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1
-DHAVE_UINT16_T=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_IPC_H=1 -DHAVE_SYS_SHM_H=1
-DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1
-DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1
-DHAVE_LIBRESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1
-DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1
-DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1
-DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1
-DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1
-DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1
-DHAVE_CPP_USING=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_I18N_LC_MESSAGES=1
-DMOZ_MAIL_NEWS=1 -DDEBUG=1 -DDEBUG_gisburn=1 -DTRACING=1
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1
-DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 -DOSTYPE=\"SunOS5\" -DOJI
-D_IMPL_NS_HTMLPARS -DXML_DTD -I../../dist/include -I../../../include
-I../../dist/include -I../../dist/include -I../../dist/include -I.
-I/usr/openwin/include -KPIC ../../../htmlparser/src/CNavDTD.cpp
"../../dist/include/nsISupportsUtils.h", line 856: Warning (Anachronism): Old
explicit specialization syntax.
"../../dist/include/nsCOMPtr.h", line 605: Warning (Anachronism): Old explicit
specialization syntax.
"../../dist/include/nsCOMPtr.h", line 848: Warning (Anachronism): Old explicit
specialization syntax.
"../../dist/include/nsFileStream.h", line 146: Error: A typedef name cannot be
used in an elaborated type specifier..
"../../dist/include/nsFileStream.h", line 147: Error: A typedef name cannot be
used in an elaborated type specifier..
"../../../htmlparser/src/CNavDTD.cpp", line 67: Warning: String literal
converted to char* in initialization.
2 Error(s) and 4 Warning(s) detected.
make[2]: *** [CNavDTD.o] Error 2
make[2]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/htmlparser/src'
make[1]: *** [libs] Error 2
make[1]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6ea/htmlparser'
make: *** [libs] Error 2
-- snip --
I'll stop here - a coworker needs my help.
It would be nice to see some comments/ideas. Thanks !
|
|
Reporter | |
Comment 12•25 years ago
|
||
Sorry, I forgot one commment - I'm currently using the Jan19-2000 sources...
|
|
||
Comment 13•25 years ago
|
||
Checking for "Workshop" is incorrect. What we were testing for is whether this version of Workshop supports the old or new C++ iostreams library. The dividing version is 5.0, i.e., Workshop 5.0 or newer supports the new iostreams library, and we need to specify a compiler flag to compile code using the old iostreams library. I suggest that you post to netscape.public.mozilla.builds or netscape.public.mozilla.unix, so that more people can take a look at this problem.
|
|
Reporter | |
Comment 14•25 years ago
|
||
I'll wait until M13 is out and then start hacking on the new milestone again. Q: What would be the right "match" term for matching Workshop 5, 6, 7 etc. ? I'm not very familar with the syntax of Makefile.in's...
|
|
Reporter | |
Comment 15•25 years ago
|
||
Small update: There are currently some problems with compiling the Zilla with Sun Workshop 6EA (this is bug 21138 - added reference) - we've to wait until this has been fixed ;-( ---- Question to cyeh@netscape.com: When will the M15 tree be closed ?
Depends on: 21138
|
||
Comment 16•25 years ago
|
||
My suggestion is to use WS5.0 and that should give you better result.
|
||
Comment 17•24 years ago
|
||
mass re-assign of all bugs where i was listed as the qa contact
QA Contact: cyeh → chofmann
|
||
Comment 18•24 years ago
|
||
How come this is still M15? M15 is already out!
|
|
Reporter | |
Comment 19•24 years ago
|
||
> My suggestion is to use WS5.0 and that should give you better result. Well, if someone pays the license... =:-) (which isn't a problem in the near future (for our institute) - but currently the only free and working sparcv9-compiler is WS6EA). ---- > How come this is still M15? M15 is already out! Ouch... my mistake... QA (chofmann@netscape.com) please kill me... ;-( I thougth it would be possible to kill all WS6-related issues before M15. Marking as M18... rich.burridge@Sun.COM posted a fix for configure.in I think the remaining problems are minor and should be kill-able before M18...
Target Milestone: M15 → M18
|
|
||
Comment 20•24 years ago
|
||
is this still an issue? cc'ing rich for his input.
|
||
Comment 21•24 years ago
|
||
I believe there are problems compiling the tip of the tree with Sun Workshop 6 compilers at the moment. I haven't "been there, done that" for a while, so it might be fixed. We at Sun are currently concentrating on generating builds for the Solaris platform (both SPARC and Intel) with the Gnu compilers. If we were using the Sun compilers, we would not be trying to generate a special 64 bit v9 version. There are already enough variables in the equation, without introducing any more. If others want to get this working that's great, but we are not devoting resources to it. We are also currently devoting minimal resources to keeping the build alive with Sun compilers. Sorry. We are a small team, and we have other higher priorities.
|
|
Reporter | |
Comment 22•24 years ago
|
||
Agreed. But it would be nice to avoid shipping "official" builds with the GNU compiler on the Solaris platform - or trying to link libstdc statically (<-- is this possible ??). The primary idea behind a 64bit SPARC version was to get rid of any portability bugs and to learn (at least for me) how to solve the problems for such a "mixed" 32bit/64bit platform like Solaris 7. ... question: Would it be possible to get the M18 source tree compiling with Sun Workshop (5/6) ?
|
|
Reporter | |
Comment 23•24 years ago
|
||
Updating milestone... M18 was long long ago... ;-(
Target Milestone: M18 → Future
|
|
Reporter | |
Comment 24•23 years ago
|
||
An attempt to build 001-04-17 CVS source snapshot looks good so far except bug 76846... Build instructions: % export CC="/opt/SUNWspro/bin/cc -xarch=v9" CXX="/opt/SUNWspro/bin/CC -xarch=v9" CFLAGS="-I/usr/include -I/usr/local/include" CXXFLAGS="-I/usr/include -I/usr/local/include" % mkdir objdir; cd objdir % export LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH_64:/usr/openwin/lib/sparcv9 % ../configure --enable-toolkit=xlib --with-xprint --enable-mathml --enable-svg --enable-xsl --enable-optimize --disable-ldap --enable-nspr-autoconf --disable-libIDLtest 2>&1 | tee -a buildlog_ws6_xlib.log % make Issues: - I am using Xlib-toolkit instead of default GTK+-toolkit to avoid playing betatester for 64bit GTK+/GDK/glib libraries (GTK+ on 64bit sparc is far away from being even in "alpha" status)... - libIDL cannot be build for 64bit sparcv9 due problems with buggy glib. Solution: use --disable-libIDLtest to disable IDL test and copy 32bit binary of "xpidl" to objdir/xpcom/typelib/xpidl/xpidl before "make" step... - Solaris 7 does not have a /usr/openwin/lib/sparcv9/libXp.so shared library. Workaround: Copy version from matching Solaris 8 Xsun patch. Solaris 8 does not have this problem. Solution: Bite Sun engineers to update their patch generation scripts to include this library... =:-) - "configure" has problems with finding some X11 libs including /usr/openwin/lib/sparcv9/libXp.so. Workaround: Set LD_LIBRARY_PATH_64 to include /usr/openwin/lib/sparcv9 Solution: Fix autoconf !? Setting target milestone to 0.9.1 - assuming noone busts Xlib-toolkit a 64bit sparcv9 Mozilla should be possible... :-)) To Rich Burridge: Can the stupid "/usr/openwin/lib/sparcv9/libXp.so.1 missing on S7"-issue be fixed (soft-links for libXp.so and sparcv9/libXp.so to /usr/lib and /usr/lib/sparcv9 are also missing on S7) if possible, please ?
|
|
Reporter | |
Comment 25•23 years ago
|
||
Retargeting to 0.9.3... many related bugs haven't been fixed yet (including Xlib-toolkit crashes) and mozilla code is not 64bit clean (when using a non-gcc compiler - and 64bit gcc doesn't create stable sparcv9 code yet)... ;-((
Whiteboard: want for mozilla 0.9.1 → want for mozilla 0.9.3
Target Milestone: mozilla0.9.1 → mozilla0.9.3
|
|
Reporter | |
Comment 26•23 years ago
|
||
2001-06-29-08-trunk build: issues: - js/src: /usr/ccs/bin/as not invoked with -xarch=v9 -- snip -- ../../config/nsinstall -R -m 444 jsautocfg.h ../../dist/include /usr/ccs/bin/as -o lock_SunOS.o -K PIC -L -P -D_ASM -D__STDC__=0 ../../../../../../../home/mozilla/src/2001-06-29-08-trunk/mozilla/js/src/lock_SunOS.s rm -f libmozjs.so /opt/SUNWspro/bin/CC -xarch=v9 -I/usr/openwin/include -mt -DDEBUG -DDEBUG_mozilla -DTRACING -g -G -Qoption ld -z,muldefs -h libmozjs.so -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o prmjtime.o lock_SunOS.o -xildoff -lm -lposix4 -ldl -lnsl -lsocket -L../../dist/bin -L/shared/bigtmp/mozilla/2001-06-29-08-trunk/objdir_ws6_gtk_sparcv9/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lposix4 -lsocket -lCrun -ldl -lm ld: fatal: file lock_SunOS.o: wrong machine class ld: fatal: File processing errors. No output written to libmozjs.so gmake: *** [libmozjs.so] Error 1 -- snip -- and then the usual "you cannot cast a 64bit ptr to 32bit int" error. -- snip -- nsAFlatString.cpp Building deps for ../../../../../../../home/mozilla/src/2001-06-29-08-trunk/mozilla/string/src/nsAFlatString.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o nsAFlatString.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_COM -D_IMPL_NS_BASE -I../../dist/include -I../../dist/include -I/shared/bigtmp/mozilla/2001-06-29-08-trunk/objdir_ws6_gtk_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_EDITOR_API_LOG=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_NEW_CACHE=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../../../../../home/mozilla/src/2001-06-29-08-trunk/mozilla/string/src/nsAFlatString.cpp "../../dist/include/nsDependentConcatenation.h", line 68: Error: Cannot cast from const void*const to unsigned. "../../dist/include/nsDependentConcatenation.h", line 74: Error: Cannot cast from const void* to unsigned. "../../dist/include/nsDependentConcatenation.h", line 81: Error: Cannot cast from const void* to unsigned. "../../dist/include/nsDependentConcatenation.h", line 145: Error: Cannot cast from const void*const to unsigned. "../../dist/include/nsDependentConcatenation.h", line 151: Error: Cannot cast from const void* to unsigned. "../../dist/include/nsDependentConcatenation.h", line 158: Error: Cannot cast from const void* to unsigned. 6 Error(s) detected. gmake[2]: *** [nsAFlatString.o] Error 6 gmake[2]: Leaving directory `/shared/bigtmp/mozilla/2001-06-29-08-trunk/objdir_ws6_gtk_sparcv9/string/src' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-06-29-08-trunk/objdir_ws6_gtk_sparcv9/string' gmake: *** [install] Error 2 -- snip -- This is bug 76846 - scc's territory... I am going to file a new bug for the other issue...
|
|
Reporter | |
Comment 27•23 years ago
|
||
Filed bug 88790 ("Build config uses wrong architecture (-xarch=...)") for the new issue...
Depends on: 88790
|
|
Reporter | |
Comment 28•23 years ago
|
||
Does anyone of the Sun staff with CVS access have the time to crawl through the source and fix those 64bit sizeof(void *)!=sizeof(int) issues ? cls suggested a seperate branch for this stuff - but unfortunately CVS access would be required... (I am sitting behind a firewall... no CVS access)...
|
||
Comment 29•23 years ago
|
||
*** Bug 76846 has been marked as a duplicate of this bug. ***
|
|
||
Comment 30•23 years ago
|
||
I have some good news and some bad news. The good news is that I managed to successfully compile Mozilla using -xarch=v9. The bad news is that it doesn't run. For some reason, I don't have a 64-bit aware version of dbx installed so I can't debug the problem at this time. Oh, and NSS doesn't compile.
|
|
||
Comment 31•23 years ago
|
||
|
||
Comment 32•23 years ago
|
||
Chris, thanx for whacking the macros for transformiix standalone. Tested that on solaris, both 64 and 32 bit. r=me on that part. Can't build mozilla though, the old "I'm not root, and won't build glib" thing. Axel
|
|
Reporter | |
Comment 33•23 years ago
|
||
cls: _THANKS!!! ---- OK... the patch looks good except for two things: 1. You did not patch Xlib-toolkit (mozilla/gfx/src/xlib/). But: No problem, I'll fix that fontmetrics stuff as part of bug 89851 2. CPP macro "fun": -- snip -- #define NS_PTR_TO_INT32(x) ((char *)x - (char *)0) #define NS_INT32_TO_PTR(x) ((void *)((char *)0 + x)) -- snip -- Please wrap the "x" parameter with "()" to avoid that some innocent coder accidently shoots him-/herself into his-/her feets... Fix: -- snip -- #define NS_PTR_TO_INT32(x) ((char *)(x) - (char *)0) #define NS_INT32_TO_PTR(x) ((void *)((char *)0 + (x))) -- snip -- Fix [2] and you have r=roland.mainz@informatik.med.uni-giessen.de No new patch required, just fix that for checkin. brendan, wanna sr= this patch, please ?
Depends on: 89851
|
|
||
Comment 34•23 years ago
|
||
To compile NSS, mozilla/configure.in and mozilla/config/autoconf.mk.in need to define a new make variable whenever the HAVE_64BIT_OS macro is defined. Then, mozilla/security/manager/Makefile.in needs to append append USE_64=1 to DEFAULT_GMAKE_FLAGS if this new make variable is defined, similar to the way it handles the USE_N32 make variable. (Search for the comment "coreconf also uses USE_64" in mozilla/security/manager/Makefile.in.)
|
||
Comment 35•23 years ago
|
||
The TestXPCInvoke.cpp changes should just use %p, not %x and an int-cast actual argument. Same goes for nsNNTPProtocol.cpp. nsTraceRefcnt.cpp should just cast pc and info.dli_saddr to (char*) and subtract rather than use NS_PTR_TO_INT32, which does the same only adds a subtraction of (char*)0 to each term. How about a revised patch with fixes for these and gisburn's comment (the macro param needs parens in transformiix too). /be
|
|
Reporter | |
Comment 36•23 years ago
|
||
Filed tracker bug for upcoming 64bit sparcv9 issues (bug 91831)... looks there is a lot of work ToDO... ;-((
|
|
Reporter | |
Comment 37•23 years ago
|
||
Yesterday I started a build based on the 2001-07-20-08-trunk nightly tarball and crawled manually througth each single compiler error. Details 1. Downloaded source tarball 2. Applied the following patches: bug 20860 attachment 42947 [details] [diff] [review] bug 42685 attachment 42685 [details] [diff] [review] bug 81311 attachment 43038 [details] [diff] [review] bug 89851 attachment 43083 [details] [diff] [review] 3. Configure: % export CC="/opt/SUNWspro/bin/cc -xarch=v9" CXX="/opt/SUNWspro/bin/CC -xarch=v9" ASFLAGS="-xarch=v9" ../src/mozilla/configure --enable-toolkit=xlib --enable-mathml --enable-svg --enable-optimize --disable-libIDLtest 4. Copied 32bit sparc xpidl binary to xpcom/typelib/xpidl/xpidl: % (cd xpcom/typelib/xpidl/; gmake -t) % cp ~/builds/2001-07-20-08-trunk/objdir_ws6_xlib/xpcom/typelib/xpidl/xpidl xpcom/typelib/xpidl/xpidl 5. Remaining build errors: -- snip -- nsLogging.cpp Building deps for ../../../src/mozilla/xpcom/base/nsLogging.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o nsLogging.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_COM -I../../dist/include -I../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../src/mozilla/xpcom/base/nsLogging.cpp "../../../src/mozilla/xpcom/base/nsLogging.cpp", line 95: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsLogging.cpp", line 424: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsLogging.cpp", line 693: Error: Cannot cast from PRThread* to int. 3 Error(s) detected. gmake[2]: *** [nsLogging.o] Error 3 gmake[2]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/xpcom/base' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/xpcom' gmake: *** [install] Error 2 ---- nsTraceRefcnt.cpp Building deps for ../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o nsTraceRefcnt.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_COM -I../../dist/include -I../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 182: Warning (Anachronism): Using void*(*)(void*,unsigned long) to initialize extern "C" void*(*)(void*,unsigned long). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 182: Warning (Anachronism): Using void(*)(void*,void*) to initialize extern "C" void(*)(void*,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 183: Warning (Anachronism): Using PLHashEntry*(*)(void*,const void*) to initialize extern "C" PLHashEntry*(*)(void*,const void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 183: Warning (Anachronism): Using void(*)(void*,PLHashEntry*,unsigned) to initialize extern "C" void(*)(void*,PLHashEntry*,unsigned). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 487: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 491: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 519: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 535: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 554: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 575: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 584: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 598: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 612: Error: Cannot cast from void* to unsigned. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 671: Error: Cannot cast from const void* to unsigned. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 766: Warning (Anachronism): Formal argument keyHash of type extern "C" unsigned(*)(const void*) in call to PL_NewHashTable(unsigned, extern "C" unsigned(*)(const void*), extern "C" int(*)(const void*,const void*), extern "C" int(*)(const void*,const void*), const PLHashAllocOps*, void*) is being passed unsigned(*)(const void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 777: Warning (Anachronism): Formal argument keyHash of type extern "C" unsigned(*)(const void*) in call to PL_NewHashTable(unsigned, extern "C" unsigned(*)(const void*), extern "C" int(*)(const void*,const void*), extern "C" int(*)(const void*,const void*), const PLHashAllocOps*, void*) is being passed unsigned(*)(const void*). "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1190: Warning: String literal converted to char* in assignment. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1191: Warning: String literal converted to char* in assignment. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1622: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1635: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1688: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1702: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1849: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1892: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1935: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1935: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1978: Error: Cannot cast from void* to int. "../../../src/mozilla/xpcom/base/nsTraceRefcnt.cpp", line 1978: Error: Cannot cast from void* to int. 15 Error(s) and 13 Warning(s) detected. gmake: *** [nsTraceRefcnt.o] Error 15 PLHashNumber(aPtr) ---- Building deps for ../../../src/mozilla/xpcom/threads/nsAutoLock.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o nsAutoLock.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_COM -D_IMPL_NS_BASE -I../../../src/mozilla/xpcom/threads/../components -I../../dist/include -I../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../src/mozilla/xpcom/threads/nsAutoLock.cpp "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 99: Warning (Anachronism): Using void*(*)(void*,unsigned long) to initialize extern "C" void*(*)(void*,unsigned long). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 99: Warning (Anachronism): Using void(*)(void*,void*) to initialize extern "C" void(*)(void*,void*). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 100: Warning (Anachronism): Using PLHashEntry*(*)(void*,const void*) to initialize extern "C" PLHashEntry*(*)(void*,const void*). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 100: Warning (Anachronism): Using void(*)(void*,PLHashEntry*,unsigned) to initialize extern "C" void(*)(void*,PLHashEntry*,unsigned). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 118: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 125: Error: Cannot cast from const void* to unsigned. "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 132: Warning (Anachronism): Formal argument keyHash of type extern "C" unsigned(*)(const void*) in call to PL_NewHashTable(unsigned, extern "C" unsigned(*)(const void*), extern "C" int(*)(const void*,const void*), extern "C" int(*)(const void*,const void*), const PLHashAllocOps*, void*) is being passed unsigned(*)(const void*). "../../../src/mozilla/xpcom/threads/nsAutoLock.cpp", line 139: Warning (Anachronism): Formal argument callback of type extern "C" void(*)(void*) in call to PR_CSetOnMonitorRecycle(extern "C" void(*)(void*)) is being passed void(*)(void*). 1 Error(s) and 7 Warning(s) detected. gmake[2]: *** [nsAutoLock.o] Error 1 gmake[2]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/xpcom/threads' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/xpcom' gmake: *** [install] Error 2 ---- Building deps for ../../../../../src/mozilla/js/src/xpconnect/src/xpcdebug.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o xpcdebug.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -DJSFILE -DJS_THREADSAFE -I../../../../dist/include -I../../../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../../../src/mozilla/js/src/xpconnect/src/xpcdebug.cpp "../../../../../src/mozilla/js/src/xpconnect/src/xpcdebug.cpp", line 336: Warning (Anachronism): Formal argument er of type extern "C" void(*)(JSContext*,const char*,JSErrorReport*) in call to JS_SetErrorReporter(JSContext*, extern "C" void(*)(JSContext*,const char*,JSErrorReport*)) is being passed void(*)(JSContext*,const char*,JSErrorReport*). "../../../../../src/mozilla/js/src/xpconnect/src/xpcdebug.cpp", line 414: Error: Cannot cast from JSObject* to unsigned. "../../../../../src/mozilla/js/src/xpconnect/src/xpcdebug.cpp", line 417: Error: Cannot cast from JSObject* to unsigned. 2 Error(s) and 1 Warning(s) detected. gmake[2]: *** [xpcdebug.o] Error 2 gmake[2]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/js/src/xpconnect/src' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/js/src/xpconnect' gmake: *** [install] Error 2 ---- Building deps for ../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o xpcwrappednative.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -DJSFILE -DJS_THREADSAFE -I../../../../dist/include -I../../../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp "../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp", line 1125: Warning (Anachronism): The operation "extern "C" JSObjectOps*(*)(JSContext*,JSClass*) == JSObjectOps*(*)(JSContext*,JSClass*)" is illegal. "../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp", line 1125: Warning (Anachronism): The operation "extern "C" JSObjectOps*(*)(JSContext*,JSClass*) == JSObjectOps*(*)(JSContext*,JSClass*)" is illegal. "../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp", line 1148: Warning (Anachronism): The operation "extern "C" JSObjectOps*(*)(JSContext*,JSClass*) == JSObjectOps*(*)(JSContext*,JSClass*)" is illegal. "../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp", line 1148: Warning (Anachronism): The operation "extern "C" JSObjectOps*(*)(JSContext*,JSClass*) == JSObjectOps*(*)(JSContext*,JSClass*)" is illegal. "../../../../../src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp", line 2352: Error: Cannot cast from XPCNativeMember* to int. 1 Error(s) and 4 Warning(s) detected. gmake[1]: *** [xpcwrappednative.o] Error 1 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/js/src/xpconnect/src' gmake: *** [install] Error 2 ---- Building deps for ../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp /opt/SUNWspro/bin/CC -xarch=v9 -o nsPresShell.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_HTML -I../../../../dist/include -I../../../../dist/include -I/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/dist/include/nspr -I../../../../../src/mozilla/layout/html/base/src/../../../xul/base/src -I../../../../../src/mozilla/layout/html/base/src/../../../xul/content/src -I../../../../../src/mozilla/layout/html/base/src/../../style/src -I../../../../../src/mozilla/layout/html/base/src/../../forms/src -I../../../../../src/mozilla/layout/html/base/src/../../../base/src -I../../../../../src/mozilla/layout/html/base/src -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_64BIT_OS=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 ../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1265: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1266: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1267: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1268: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1269: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1270: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1271: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 1272: Warning: String literal converted to char* in initialization. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 4578: Warning: String literal converted to char* in formal argument aReason in call to nsIFocusController::SetSuppressFocus(int, char*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 4611: Warning: String literal converted to char* in formal argument aReason in call to nsIFocusController::SetSuppressFocus(int, char*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7191: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7197: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7237: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7308: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7343: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7403: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7424: Error: Cannot cast from void* to int. "../../../../../src/mozilla/layout/html/base/src/nsPresShell.cpp", line 7449: Warning (Anachronism): Formal argument f of type extern "C" int(*)(PLHashEntry*,int,void*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C" int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(PLHashEntry*,int,void*). 1 Error(s) and 17 Warning(s) detected. gmake[3]: *** [nsPresShell.o] Error 1 gmake[3]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/layout/html/base/src' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/layout/html/base' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-07-20-08-trunk/objdir_ws6_xlib_sparcv9/layout/html' gmake: *** [install] Error 2 -- snip -- After all, the build succeded. I deleted the objdir and restarted the build to check it again - build works... ...but the binary crashes... ;-( I am going to file bugs for that...
|
|
Reporter | |
Comment 38•23 years ago
|
||
Retargeting to milestone 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
|
Reporter | |
Comment 39•23 years ago
|
||
cls: Wanna file a new patch, even a partital solution for now, please ? Otherwise the work gets rotten soon... ;-(
|
|
||
Comment 40•23 years ago
|
||
Roland: feel free to pick up the work as I'm not going to get back to this for awhile. xptcall still needs to be implemented for sparc v9 before this patch is actually useful.
Since this is targetted to 0.9.4, could you remove the "want for mozilla 0.9.3"?
|
|
Reporter | |
Comment 42•23 years ago
|
||
dbaron: Oh... yes... I forgot to update that in my mass-move-to-0.9.4... ;-(
Whiteboard: want for mozilla 0.9.3 → want for mozilla 0.9.4
|
|
||
Comment 43•23 years ago
|
||
|
|
||
Comment 44•23 years ago
|
||
I reviewed the patch for mozilla/security/manager/Makefile.in. This is unnecessary but harmless: +ifndef HAVE_64BIT_OS FREEBL_PURE32_MODULE = libfreebl_pure32_3$(DLL_SUFFIX) FREEBL_HYBRID_MODULE = libfreebl_hybrid_3$(DLL_SUFFIX) +endif Thanks Chris!
|
|
Reporter | |
Comment 45•23 years ago
|
||
I started a build using that new patch with Sun Workshop 6 Update 2 FCS. I'll report back in ~12 hours...
|
|
Reporter | |
Comment 46•23 years ago
|
||
|
|
Reporter | |
Comment 47•23 years ago
|
||
Filed new patch... same as cls's patch + fixes required to compile a debug build using Sun Workshop 6 Update 2 FCS... Requesting r=/sr= for that monster, please... :-)
|
||
Comment 48•23 years ago
|
||
i was asked to review this patch, but it's a bit beyond me. My observation-without-knowledge is that it looks fine, but that the larger brained (wtc, brendan, tor) should be doing the reviewing.
|
|
||
Comment 49•23 years ago
|
||
|
|
||
Comment 50•23 years ago
|
||
|
|
||
Comment 51•23 years ago
|
||
Beware sign-filling right shift. You've changed these places, at least, to crud
up hash codes with all-ones high order bits on some platforms. This may not
matter once multiplicative hash has done its thing, but it may if the table gets
big enough. I say wrap PLHashNumber() casts around the NS_PTR_TO_INT32 calls
that are left operands of >>, throughout the patch.
@@ -74,7 +75,7 @@
return "nsOutlinerRowTestNode::Element"; }
virtual PLHashNumber Hash() const {
- return PLHashNumber(mResource.get()) >> 2; }
+ return NS_PTR_TO_INT32(mResource.get()) >> 2; }
virtual PRBool Equals(const MemoryElement& aElement) const {
if (aElement.Type() == Type()) {
diff -r -u original/mozilla/content/xul/templates/src/nsRDFConInstanceTestNode.h
mozilla/content/xul/templates/src/nsRDFConInstanceTestNode.h
--- original/mozilla/content/xul/templates/src/nsRDFConInstanceTestNode.h Wed Apr 4 06:59:52 2001
+++ mozilla/content/xul/templates/src/nsRDFConInstanceTestNode.h Wed Aug 1 02:48:39 2001
@@ -24,6 +24,7 @@
#ifndef nsRDFConInstanceTestNode_h__
#define nsRDFConInstanceTestNode_h__
+#include "nscore.h"
#include "nsRDFTestNode.h"
#include "nsFixedSizeAllocator.h"
#include "nsIRDFResource.h"
@@ -99,7 +100,7 @@
return "nsRDFConInstanceTestNode::Element"; }
virtual PLHashNumber Hash() const {
- return (PLHashNumber(mContainer.get()) >> 4) ^
+ return (NS_PTR_TO_INT32(mContainer.get()) >> 4) ^
PLHashNumber(mContainerTest) ^
(PLHashNumber(mEmptyTest) << 4); }
diff -r -u original/mozilla/content/xul/templates/src/nsRDFConMemberTestNode.h
mozilla/content/xul/templates/src/nsRDFConMemberTestNode.h
--- original/mozilla/content/xul/templates/src/nsRDFConMemberTestNode.h Wed Apr 4 06:59:54 2001
+++ mozilla/content/xul/templates/src/nsRDFConMemberTestNode.h Wed Aug 1 02:48:39 2001
@@ -24,6 +24,7 @@
#ifndef nsRDFConMemberTestNode_h__
#define nsRDFConMemberTestNode_h__
+#include "nscore.h"
#include "nsRDFTestNode.h"
#include "nsIRDFDataSource.h"
#include "nsFixedSizeAllocator.h"
@@ -94,8 +95,8 @@
return "nsRDFConMemberTestNode::Element"; }
virtual PLHashNumber Hash() const {
- return PLHashNumber(mContainer.get()) ^
- (PLHashNumber(mMember.get()) >> 12); }
+ return NS_PTR_TO_INT32(mContainer.get()) ^
+ (NS_PTR_TO_INT32(mMember.get()) >> 12); }
virtual PRBool Equals(const MemoryElement& aElement) const {
Why not just use %p and the pointer actual arg here?
@@ -4448,7 +4449,7 @@
{
entry = (OffsetEntry *)mOffsetTable[i];
printf("ENTRY %4d: 0x%.8x %c %c %4d %4d %4d\n",
- i, (PRInt32)entry->mNode, entry->mIsValid ? 'V' : 'N',
+ i, NS_PTR_TO_INT32(entry->mNode), entry->mIsValid ? 'V' : 'N',
entry->mIsInsertedText ? 'I' : 'B',
entry->mNodeOffset, entry->mStrOffset, entry->mLength);
}
The transformiix code is just wacky, it casts pointers that may be null to MBool
to synthesize 0 and non-zero C-boolean values (which are not, of course, always
0 or 1!). Rather than perpetuate this in a warning-free fashion, let's fix such
cases as:
@@ -283,9 +284,9 @@
MBool txListIterator::hasNext() {
MBool hasNext = MB_FALSE;
if (currentItem)
- hasNext = (MBool) currentItem->nextItem;
+ hasNext = NS_PTR_TO_INT32(currentItem->nextItem);
else if (!atEndOfList)
- hasNext = (MBool) list->firstItem;
+ hasNext = NS_PTR_TO_INT32(list->firstItem);
return hasNext;
} //-- hasNext
to use 'hasNext = (currentItem->nextItem != nsnull);' and similar, throughout.
Unless MBool is really specified as 0 or non-zero. But then, could we not some
bad day find a 64-bit architecture where the low 32 bits of a non-null pointer
are all 0? Hmm. Cc'ing peterv.
Same problem for nsViewSourceHTML.cpp, the mShowErrors assignment.
Similar problem in wpcwrappednative.cpp, where instead of NS_PTR_TO_INT32'ing
the return value of iface->FindMember just to cast to a JSBool, simply compare
the returned pointer != nsnull to synthesize a proper boolean value.
Ah, I seem some later files, to preserve PLHashNumber() (or old C-style equiv)
casts -- cool. Just need that all around, when right-shifting.
/be
|
|
||
Comment 52•23 years ago
|
||
|
|
||
Comment 53•23 years ago
|
||
I checked in the 2001-08-07 security patch (attach_id=45088) for mozilla/security/manager/Makefile.in.
|
|
||
Comment 54•23 years ago
|
||
cls, gisburn: thanks for your patience, looks good to me (although where did the iface->FindMember patch in js/src/xpconnect/src/xpcwrappednative.cpp go? I must be caffeine-deprived). Anyway, r/sr=brendan@mozilla.org. /be
|
|
||
Comment 55•23 years ago
|
||
nitpick, there is no nsnull for transformiix standalone. Could you add that to baseutils.h, too? Other than that, the transformiix stuff looks good, though I don't have cycles to test it, sorry. Peter came back from vacation today, no idea about his cycles (he found the nsnull, though). Axel
|
||
Comment 56•23 years ago
|
||
The changes look good to me except for nsnull. Either declare it in baseutils.h or use NULL. With that r=peterv. Small nit, I prefer + hasNext = (currentItem->nextItem != nsnull); instead of + hasNext = currentItem->nextItem != nsnull; Thanks for keeping our standalone Transformiix build in mind.
|
||
Comment 57•23 years ago
|
||
I plan to add the nscore.h change to bug 31770 (unless this gets checked in first) - I want the #defines for int32 <-> void*.
The changes checked in to nsTraceRefcnt.cpp last night (which were not in the reviewed patch) that changed 0x%08X to 0x%08p broke the nsTraceRefcnt log format. It's printing 0x0x12345678 instead of 0x12345678. Furthermore, if I remember correctly: * %p puts 0x on some platforms and not others * %08p doesn't behave any differently than %p, at least on one machine (some Linux) where I tested it. Could you come up with a better solution that doesn't break existing code?
|
|
||
Comment 59•23 years ago
|
||
r=dbaron. The probability pointers on a 64-bit machine having a common low 32 bits seems very low to me. And if it ever is a problem, we can cross that bridge when we come to it.
|
|
||
Comment 61•23 years ago
|
||
sr=brendan@mozilla.org, sorry about that bustage -- I foolishly thought that %p works the way it should, instead of being horribly broken on some platforms. Yet another portability guide line-item. /be
|
|
||
Comment 62•23 years ago
|
||
Just curious -- why can't you use %p? %p is the only portable way to print a pointer. I understand that different platforms print the %p format in different ways, but it would seem that if the log file parser uses fscanf with %p, it should be able to parse the output of fprintf with %p on the same platform, no matter how the %p format is printed. Casting a pointer to a 32-bit integer will be a problem down the road. It is just a matter of time.
|
|
||
Comment 63•23 years ago
|
||
What if the log file scanner is Perl? At least we can count on %p being primitive (as in, composable with 0x and # and so on) in PR_s*printf, eh? Maybe that's the solution: PR_snprintf into a big- enough buffer and then log that? /be
|
|
||
Comment 64•23 years ago
|
||
Using PR_snprintf to print pointers should work. I am not sure if %p is composable with 0x and # and so on in PR_snprintf though.
|
|
||
Comment 65•23 years ago
|
||
From a quick reading, %p seems to be composable, although I can't find any support for # in prprf.c (no big deal, as the comment in that file containing '#' says, it's vaguely specified). So 0x%p will not double 0x, and 0x%08p will zero-pad on the left to a field width of 8. /be
|
|
||
Comment 66•23 years ago
|
||
Maybe you want 0x%016p? 0x08p will truncate 64-bit pointers.
I don't want to constantly have to type 8 extra 0's when I'm working on a 32-bit machine.
I guess dropping the 0-padding would probably be OK.
|
|
||
Comment 69•23 years ago
|
||
wait -- wtc, are you sure 0x%08p will truncate? I thought only precision (e.g., 0x%.8p) would do that. Field width should never truncate. /be
|
|
Reporter | |
Comment 70•23 years ago
|
||
What's status of this bug ? Are all parts of the patch in CVS ?
|
|
Reporter | |
Comment 71•23 years ago
|
||
Retargeting to 0.9.6 for now...
Target Milestone: mozilla0.9.4 → mozilla0.9.6
|
||
Comment 72•23 years ago
|
||
Sorry I'm late to this party (no one invited me). Maybe I'm just being dense... But, I was about to question the scheme of sprinking these NS_PTR_TO_INT32 macros all over the place when I realized that I was confused. And much of the reason I was confused is because the macros (as I see it) are simply misnamed. Why are the macros called NS_PTR_TO_INT32 and NS_INT32_TO_PTR when that is not exactly what the implementations seems to do? Why not NS_PTR_TO_UINT and NS_UINT_TO_PTR? Or, is there magic I'm missing that makes... #define NS_PTR_TO_INT32(x) ((char *)(x) - (char *)0) ...somehow create a 32 bit value on a machine with 64bit pointers? And can someone vend a clue on why this special treatment is necessary for this flavor of 64bit architecture? Does it have magic twisted pointers that simply defy being treated as numbers? Do they actually yield 32bit values after having (char*)0 subtracted from them?!? Also, I notice that lots of them are in cases where we do bit twiddling to create hash numbers. Would it be out of the question to make the hashtable implementations deal with pointer sized hash numbers rather than the uint32 size numbers they have now? Even if the macros are still required, aren't we likely to regret the loss of half the bits when we cast down to uint32? (or, again, is there magic going on?) And, what is the strategy on fixing brainprint? I'm mean, aren't people going to just keep adding code that breaks this platform? How do we get the word out? And what *exactly* is the word going to be? Apparently we can't even cast pointers to PRBool anymore? [Hey, did anyone notify module owners on this one?] TIA for any clues you can send my way.
|
||
Updated•23 years ago
|
Whiteboard: want for mozilla 0.9.4
|
|
||
Comment 73•23 years ago
|
||
*** Bug 65555 has been marked as a duplicate of this bug. ***
|
|
||
Comment 74•23 years ago
|
||
That's my mistake on the naming. I came to the same conclusion (int32 vs uint) after the fact but didn't want to go back and rename everything. FWIW, I believe uint is still a 32bit int. (long changes size going to 64bit but int should still be the same) scc may be a better person to speak on the subtraction as its just a macro version of his fix from bug 76846. The Forte compiler is just extremely picky. We've had OSF/1 builds for some time which are also 64-bit and never ran into the casting problem. They do have some problems with the 32-bit assumptions though (bug 96261). The immediate plan was to get this platform and its picky compiler off the ground so that we have a platform/compiler that we can actually use as a testbed when 64bit problems crop up. As for fixing brainprint, I thought that we'd eventually update the coding guidelines once we figured out what works. No, all of module owners weren't modified as this should not have changed their code (except the printfs I screwed up) sans making the implicit explicit.
|
|
||
Comment 75•23 years ago
|
||
The C standard (which I can't quote accurately right now) says that you can take the difference of two pointers, but only in certain circumstances (pointers to elements in the same array, or into memory that can be treated as if it were an array, or something like that). I believe the type is ptrdiff_t; it certainly isn't int32 (PRInt32), and shame on me for not catching that. OTOH, what the hash functions in particular want is a void*-sized integral type. We can fix this, belatedly. How about NS_PTR_TO_PTRDIFF_T? Ugh. Maybe we can avoid stuttering and say NS_PTR_TO_DIFF or some such. C language lawyers (dbaron, you're on retainer!), please jump in. /be
|
|
||
Comment 76•23 years ago
|
||
Forgot to add that the difference is signed, not unsigned, in general. Although you would expect (char*)p - (char*)0 to yield a non-negative number, it need not in. ptrdiff_t is a signed type. /be
|
|
||
Comment 77•23 years ago
|
||
That all sounds pretty reasonable to me. I want to reiterate the idea that the places where we find ourselves using this macro are suspect. One amusing example that came up was in jst's code... - return history->Item(PRUint32(aNative), aResult); + return history->Item(NS_PTR_TO_INT32(aNative), aResult); ...He meant to pass the PRInt32 'aIndex' and passed the pointer 'aNative' instead. The need to use the macro actually could have brought this error to light. As it happened, he already knew about it and had a fix queued up.
|
|
||
Comment 78•23 years ago
|
||
I'm going to pitch my vote for NS_PTR_TO_INTEGER. I think DIFF would be too ambigious unless you knew exactly what the macro did beforehand. INTEGER instead of INT because ptrdiff is a long on 64 bit platforms (checked sparcv9/solaris & alpha/osf1). (I suppose we really want NS_PTR_TO_BASE_10_REPRESENTATION_OF_PTR .) Perhaps the macro should include the explicit cast to ptrdiff_t just to make the point clear? #define NS_PTR_TO_INTEGER(x) ((ptrdiff_t)((char *)(x) - (char *)0)) #define NS_INTEGER_TO_PTR(x) ((void *)((char *)0 + ((ptrdiff_t)x))) FYI, with the fixes from 91840, we have a sparcv9 build running (debug anyway). There are some quite noticable layout issues and Pavlov says that some of the underlying gtk code needs to be made 64bit aware. These explicit macro casts should give us a reasonable pointer (no pun indeed) to potential problem areas in the code.
|
|
||
Comment 79•23 years ago
|
||
(cls: not base 10, it's still a binary integer representation.) #define NS_PTR_TO_INTEGER(x) ((ptrdiff_t)((char *)(x) - (char *)0)) #define NS_INTEGER_TO_PTR(x) ((void *)((char *)0 + ((ptrdiff_t)x))) I'm still waiting for chapter and verse from the C standard, but want to point out that the second line should read: #define NS_INTEGER_TO_PTR(x) ((void *)((char *)0 + (ptrdiff_t)(x))) Always parenthesize macro parameters, and don't overparenthesize casts against lower-precedence operators such as +. One more nit: PTR seems nice and terse, but INTEGER drags on. I'd settle for INT, but am open to better names all around. /be
|
|
||
Comment 80•23 years ago
|
||
I vote for INT over INTEGER - it's totally clear (and matches the official type name "int"). The macros as last given look correct. It is true that the C spec states that the result of subtraction of pointers is only guaranteed valid if they're in the same array. However, the macros given should work for all C compilers I've ever heard of. The only thing I can think of that _might_ make it trivially more compliant/portable (and I emphasize the "might") would be to use NULL (or (char *) NULL) instead of (char *) 0. I can't think of any real-world instance where that would matter, however, and one could make arguments against it, perhaps.
|
|
||
Comment 81•23 years ago
|
||
If a compiler does not allow you to cast a 64-bit pointer
to a 32-bit integer, you just need to add an intermediate
cast to size_t or ptrdiff_t (a long is not guaranteed to
be big enough to hold a pointer). For example,
int i;
char *p;
i = (int) p; /* bad */
i = (int)(size_t) p; /* good */
i = (int)(ptrdiff_t) p; /* also good */
The way you define the NS_PTR_TO_INTEGER macro is not
portable because it takes the difference between an
arbitrary pointer and 0.
#define NS_PTR_TO_INTEGER(x) ((ptrdiff_t)((char *)(x) - (char *)0))
I guess the reason you do this is that ptrdiff_t is
supposed to hold a pointer difference. I think you
just need to say
#define NS_PTR_TO_INTEGER(x) ((ptrdiff_t)(x)) /* signed */
or
#define NS_PTR_TO_INTEGER(x) ((size_t)(x)) /* unsigned */|
|
||
Comment 82•23 years ago
|
||
OK, here is a better suggestion. The problem at hand is an integer type such that any pointer can be converted to this type and back again, with the result equal to the original pointer. C89 does not have this integer type. size_t and ptrdiff_t are the closest things we have in C89. C99 defines an *optional* type intptr_t in <stdint.h>. So it seems that Mozilla can define a type ns_intptr_t as follows: #ifdef HAVE_INTPTR_T #include <stdint.h> typedef intptr_t ns_intptr_t; #else #include <stddef.h> typedef ptrdiff_t ns_intptr_t; #endif and the NS_PTR_TO_INTEGER as follows: #define NS_PTR_TO_INTEGER(x) ((ns_intptr_t)(x))
|
|
||
Comment 83•23 years ago
|
||
Couldn't find stdint.h on my solaris 7 box, WS5.0 and 4.2.
|
|
||
Comment 84•23 years ago
|
||
Ok, I tested a build using ptrdiff_t and it compiled and seems to work no worse than what we had before. So, I'm assuming that we want to just switch to casting to ptrdiff_t (or PRPtrdiff) now? Is it really true that a long (which changes sizes with the platform) is not guaranteed to be the size of a pointer? The fix for bug 98686 seems to make the opposite assumption. My solaris 7 box doesn't have stdint.h but (u)intptr_t is defined in <sys/int_types.h> .
|
|
||
Comment 85•23 years ago
|
||
> Is it really true that a long (which changes sizes
> with the platform) is not guaranteed to be the size
> of a pointer?
Microsoft gave us a counterexample. In 64-bit Windows,
only pointers are 64 bit; a long is still 32 bit.
All the other 64-bit operating systems use the LP64
data model, which means both longs and pointers are
64 bit (and hence the same size).|
|
Reporter | |
Comment 86•23 years ago
|
||
> Microsoft gave us a counterexample. In 64-bit Windows,
> only pointers are 64 bit; a long is still 32 bit.
And know we all know how smart M$-"engineers" are... ;-((|
|
||
Comment 87•23 years ago
|
||
There's no guarantee in C/C++ that a long can hold a pointer, which was one of the reasons for all the ptrdiff_t/foo_t/etc types. Now, the number of machines/compilers that _don't_ allow a long to hold a pointer has always been small (and probably included some older processors, and some weirder machines; perhaps IBM 370's, or machines based on non-flat addressing) - at least until now.
|
|
||
Comment 88•23 years ago
|
||
cls: use intptr_t if you can find it in a system header, I suppose; fall back on ptrdiff_t. In the bad old Win16 (Windows 3.1) daze, we found that ptrdiff_t was a signed 16 bit int using the MS compiler! This can't even express the difference between array element addresses if the array is > 32K in size. I've always believed that MS was violating the standard with that ptrdiff_t size choice, but I have never had the time to play language lawyer. Someone care to help now? This matters if ptrdiff_t could legally be 32 bits on a *P64 system. /be
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
|
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.8
|
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → Future
|
|
||
Comment 89•21 years ago
|
||
Mass reassign to default build config owner
Assignee: cls → mozbugs-build
Priority: P3 → --
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Target Milestone: Future → ---
|
|
||
Updated•20 years ago
|
Assignee: leaf → cmp
Severity: normal → minor
Priority: -- → P4
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
|
||
Updated•19 years ago
|
Assignee: chase → build
|
||
Comment 91•18 years ago
|
||
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to build@mozilla-org.bugs reflects reality. If there is a bug you really think we need to be looking at, please *email* build@mozilla.org with a bug number and explanation.
Assignee: build → nobody
|
||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•