Closed Bug 21138 Opened 25 years ago Closed 23 years ago

Compilation of src with "Sun Workshop 6 Update 2 EA" fails at various points...

Categories

(Core Graveyard :: Tracking, defect, P3)

Product:
Core Graveyard
Component:
Tracking
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.3

People

(Reporter: roland.mainz, Assigned: cls)

References

Details

Attachments

(3 files)

Build logs for tip 2000-05-03-08-M16 with Sun Workshop 6EA...
59.42 KB, application/octet-stream
Details
Build logs attempting to build 2000-12-06-08-Mtrunk with WS6
52.59 KB, application/octet-stream
Details
Build log from mozilla-2001-02-11-08-Mtrunk tarball using Sun Workshop 6 Update 1 EarlyAccess
826.39 KB, text/plain
Details 
I'd like to use the Sun Workshop compiler (cc/CC) to create a sparcv9 build of
Mozilla, but the current tarballs (M11, 19991206) don't compile.
Is it possible to step through all errors and hack this working BEFORE M12 ?

-- snip --
make[3]: Entering directory
`/home/gisburn/package-builds/mozilla5/mozilla-M11/nsprpub/lib/prstreams'
cc -xstrconst -o SunOS5.7_sparc_32_PTH_OPT.OBJ/plvrsion.o -c  -O -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 -UDEBUG -DNDEBUG
-I/home/gisburn/package-builds/mozilla5/mozilla-M11/objdir_sparcv9/dist/include
-ISunOS5.7_sparc_32_PTH_OPT.OBJ plvrsion.c
CC -Qoption cg -xstrconst -o SunOS5.7_sparc_32_PTH_OPT.OBJ/prstrms.o -c  -O
-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 -UDEBUG -DNDEBUG
-I/home/gisburn/package-builds/mozilla5/mozilla-M11/objdir_sparcv9/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_OPT.OBJ/prstrms.o] Error 1
make[3]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla-M11/nsprpub/lib/prstreams'
make[2]: *** [export] Error 2
make[2]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla-M11/nsprpub/lib'
make[1]: *** [export] Error 2
make[1]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla-M11/nsprpub'
make: *** [export] Error 2
-- snip --
I have a successful build with Sun Workshop 5.0 compiler on M13.
I have applied a patch for the compiler as well as a patch for bug 20297.

My understanding is that in order to build a 64-bit application (assuming
that's what the mentioned sparcv9 build refers to), a specific compiler
option has to be provided (-sparcv9 if I recall correctly) which I do not
see from the output below.
> option has to be provided (-sparcv9 if I recall correctly) which I do

This is "-xarch=v9" or better: "-xarch=v9a" (to include VIS support as well).
But my 1st attempt was to get a working 32bit Mozilla with Sun Workshop 6EA,
fix&&kill all problems. then try to compile the 64bit version...

My understanding is that there's already a bug filed against Workshop EA6 for 
missing streampos in iostream.h.  The bug was already fixed.  I am tracking
it down to see if the bug fix is already available to external user or not.
Got some info from the compiler folks.  
If you are using WS6 EA installation, an update will soon be available (in a 
  week or two, I am told :-) ).  This update has many bug fixes (which should
  include this one) and enhancements.
If you are using WS5, this bug is fixed in the latest compiler patch,
  #107311-09.
A temporary workaround would be:  edit the iostream file in ../WS6/include/CC
  to add the line "using std::streampos; after all the #include directives. 

Again, I have successfully built M13 with the latest 5.0 compiler + a patch
  to bug 20297.

Hope it helps.
I tried to compile the 16.2.2000 tarball with WS6EA(incl. 1.2.2000 update and
all patches for Solaris 2.7/MU4) and got the following result:
-- 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_OSTREAM=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 -DDETECT_WEBSHELL_LEAKS=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 985: Warning (Anachronism): Old
explicit specialization syntax.
"../../dist/include/nsCOMPtr.h", line 632: Warning (Anachronism): Old explicit
specialization syntax.
"../../dist/include/nsCOMPtr.h", line 873: 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 am not sure if the WS6EA update which you've installed has the fix to this
problem.  I do not have WS6EA on my machine.  Did you see that the iostream file
in ../WS6/include/CC has the line "using std::streampos;" somewhere after all
the #include directives?  If you don't, it's probably that you will have to
wait till the next update which should be coming soon.  Anyway, this time
you seem to have a different but related error message.
To mtchan@eng.sun.com: It seems that I have to wait for the next Sun WS6EA
update ;-(
Is it possible to get a notification mail is the update is available ? Thanks !
I am checking to see if there is a notification mailing list anywhere.  If 
I cannot locate one, I will try my best to give you an update for WS6EA update
5.
Looked like WS6EA update 5 is available now!
I've updated my WS6EA installation to version "23.2.2000" (<-- or whatever it is
named), but the build still breaks (M14 source tarball) -  gcc 2.95.1 build
works (except MathML...):

Build sequence was:
mkdir objdir
cd objdir
../configure
make

And the error was:
-- 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_OSTREAM=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 -DDETECT_WEBSHELL_LEAKS=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 985: Warning (Anachronism): Old
explicit specialization syntax.
"../../dist/include/nsCOMPtr.h", line 632: Warning (Anachronism): Old explicit
specialization syntax.
"../../dist/include/nsCOMPtr.h", line 873: 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_ws6/htmlparser/src'
make[1]: *** [libs] Error 2
make[1]: Leaving directory
`/home/gisburn/package-builds/mozilla5/mozilla/objdir_ws6/htmlparser'
make: *** [libs] Error 2
-- snip --

Heeeelllpppp...
What is the output of this command " CC -V " for the Sun Workshop 6 EA compiler?
Updating QA Contact.
QA Contact: leger → mcafee
CC says:
-- snip --
% CC -V
CC: Sun WorkShop 6 2000/02/03 C++ 5.1 Dev
-- snip --

cc says:
-- snip --
% cc -V
cc: Sun WorkShop 6 2000/01/09 C 5.1 Dev
usage: cc [ options] files.  Use 'cc -flags' for details
-- snip --
Blocks: 20860
Added reference to bug 20860 (sparcv9 build of Mozilla) - IMHO there's no way to
get sparcv9 binaries without Sun Workshop 6EA (binaries from recent gcc sparcv9
builds aren't stable yet ;-(  )...
To mtchan@eng.sun.com: I filed bug 31004 because WS6EA dmake can't be used to
build Mozilla. Any comments ?

I guess you are trying to fix too many problems all at once.  I am trying to
stay focus with this bug which you have addressed here and not be distracted by
the other bugs which you have mentioned about dmake and sparcv9 build.  From
your reply on the output of "CC -V", it certainly points out a problem in the
file configure.in where we have to take some special actions for WS5.0 because
of different vtable format.  Although WS6 (with C++ 5.1) will be using the same
vtable format, we should be able to add 5.1 in the configure.in file and keep
the build going; the question is whether or not we should fix it now.
WS6EA (namely WS6 Early Access) is still in development at the moment, would it
be better for us to wait till later for a more stable version before we make any
changes specially for it (e.g., What if...the version number being changed when
it gets closer to release time...it has happened before for some other
products).  Perhaps you should try the 5.0 version which also give you the
capability to build in 64 bit!!  Then you will be able to move on to address
other issues instead of getting blocked by this.  I and some people
can successfully build it with the WS5.0 compiler.  This bug is definitely
not a blockage of 20860 because you don't need to successfully build mozilla
with WS6EA before you try the sparcv9 build!!  sparcv9 build is a released
feature for WS5.0 compiler.

mtchan@eng.sun.com, you're right.
But there's simply one reason for not using WS5.0 (for us..): No money left last
year (instead, we spend the remaining pennies in two E250). Therefore WS6EA is
currently my only source of sparcv9 binaries.
The sparcv9 build was only the idea to kill any portability-related bugs out of
Mozilla. And last-but-not-least the "dmake" was the idea of making our "bunch"
of Ultra-5 monsters happy (and checking for bugs&&missing features in dmake)...

[richb - 4/20/00]
Roland, I'd like to address the original intention of this bug; namely building
Mozilla against WS5.0 compilers. We have no problem doing that here at Sun.
WS 5.0 has the following three patches applied: 107357-07, 107289-05 and
107311-09). All of those patches are downloadable from the Sun patch servers.
If Mozilla fails to build with WS6EA, file another bug. I'm sorry you have
no money to buy Sun compilers, but that is beyond the scope of this bug.
Unless you can give a compelling reason to leave this bug open, I suggest it
should be closed as fixed.
Unless you have a compelling
[richb - 5/2/2000]
Mozilla happily compiles with Sun Workshop 6.0 (beta) compilers. If you
make the following change to configure.in:

stard[109] diff -c configure.in.orig configure.in
*** configure.in.orig	Tue May  2 08:43:01 2000
--- configure.in	Tue May  2 08:49:05 2000
***************
*** 1732,1738 ****
      dnl a set of libraries).  Aurgh.
      case $target in
      *-solaris*)
! 	if test ! -z "`${CC} -V 2>&1 | head -1 | grep '5.0'`" && test
"$SUNWSPRO5_VTABLE"; then
  	    CXX="$CXX -library=iostream"
  	    LIBS="-liostream -lCrun $LIBS"
  	else
--- 1732,1738 ----
      dnl a set of libraries).  Aurgh.
      case $target in
      *-solaris*)
! 	if test ! -z "`${CC} -V 2>&1 | head -1 | grep '5.[01]'`" && test
"$SUNWSPRO5_VTABLE"; then
  	    CXX="$CXX -library=iostream"
  	    LIBS="-liostream -lCrun $LIBS"
  	else

Note that the version number of the Sun Workshop 6.0 compilers is currently
5.1. It's unknown if this might change before FCS release of the compilers.
To Rich Burridge:
Thanks for the patch (it does that part automagically what I manually edited the
last months for each build... ;-( )

Anyway it _should_ work. But it does not ;-(
Newest incarnation of those nasty problems:
-- snip --
/opt/SUNWspro/bin/CC -library=iostream  -mt -O -g -o regExport regExport.o
-xildoff -L../../../dist/bin -L../../../dist/lib  -L/usr/local/lib
-L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext
-lX11 -lsocket -lnsl -lm -L../../../dist/bin -lplds4 -lplc4 -lnspr4 -lpthread
-L../../../dist/bin -lxpcom  -lw -lposix4 -lintl -lelf -lnsl -lsocket -lresolv
-liostream -lCrun -ldl -lm   
Undefined                       first referenced
 symbol                             in file
__eprintf                           ../../../dist/bin/libnspr4.so
ld: fatal: Symbol referencing errors. No output written to regExport
-- snip --

OK, if I remember correctly eprintf() is one of the gcc-library shortcuts for
fprintf(stderr,...).
But: I'm not linking with any GNU library or with any library which was build
with gcc.
Checking libnspr4.so:
-- snip --
% ldd dist/bin/libnspr4.so
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
-- snip --

I ran "tgrep" (sort of grep over multiple files - nice RAID killer =:-) over the
sources... Mozilla code doesn't make use of eprintf().

The only thing which I can imagine is that somewhere gcc-includes are referenced
accidently which use eprintf() - but how to track that down ?
Any ideas ?

----

> I'm sorry you have no money to buy Sun compilers

Thanks, but I "fixed" this issue :-)) 
We'll buy WS6 FCS as soon as it will be available. Is it possible to give me
some _raw_ hints what it will cost in europe (germany+england) ?

Could you attach a transcript of the configure portion of your 6.0 build?
I'll compare it with mine. I've no idea of the price of SW6.0; you should
ask yoir salesperson.
Hi Roland:  What compiler do you use to build the gtk, glib, libIDL libraries?
I do not seem to see -L<gtk, etc. path> in your compile line.
Wonder if it will accidentally picks up the gnu-build version of
those libraries.  Those libraries need to be compiled with the
same compiler as well, and we usually run configure to pick up
these libraries before building mozilla.  Just a thought.
To Margaret Chan: I don't have any gcc-build GTK/GLIB/IDL-libs anymore. I
pkrm'ed my gcc-build-packages and replaced them by packages build with WS6EA
(which can also be used to build apps. with gcc)...

I'll attach the build logs in a few secs...
I've attached a tar.gz with the following files:
config.cache
config.log
config.status
mybuild.log (make 2>&1 | tee -a mybuild.log)

-> seawood, can you have a look
Assignee: chofmann → cls
Roland, can you build & run the nspr tests under nsprpub/pr/tests?
Also, can you make sure that you do a 'make realclean' inside of nsprpub ?  I
noticed in your log file that you didn't rebuild any nspr libs.
Status: NEW → ASSIGNED
Another cry for a status update.

Updated "subject"... we now have Forte 6... :-)

I would still vote to get this
a) fixed
b) ship the "official" Sun-branded Mozilla/netscape 6 build with Workshop 6

Why ?
1. Performance
2. ABI stability. gcc's C++ name mangeling isn't stable and won't be stable (at
least three incompatible changes (including gcc 3.x ABI changes)), making it
very difficult to ship binary-only plugins. 
gcc/linux people may not care about binary compatiblity on their platforms as
they normally have the source ("recompile that, that it will work again..."),
but Solaris customers&users normally expect binary compatibility...

To [1]:
I assume that Mozilla compiled with Sun Workshop 6/Forte compiled with -fast
will be faster than gcc... but is there any other way to quish more out of the
bytes (what about using -xcrossfile - can this be used for building shared libs
?) ?

I agree with the Sun engineer (who said that ? - I cannot remember that anymore)
that it consumes much time, but IMHO it would be usefull to _try_ to get each
milestone working with Workshop 5/6 compilers...
Summary: Compilation of src with Sun Workshop 5/6EA fails at various points... → Compilation of src with Sun Workshop 5/6 fails at various points...
Updating the Summary as Mozilla has compiled with the Workshop 5.0 compiler for
quite some time now (see the nebiros tinderbox on the SeaMonkey-Ports page).
There is a minimal list of patches available at
http://www.mozilla.org/unix/solaris.html that you will need to apply for the
WS5.0 build to work.

Since you never responded to my request about making sure that nspr was
recompiled from scratch (to resolve the question about gcc-specific symbols
creeping into the build), we're going to take this from scratch.  Start with a
build from scratch.  We're going to need the usual info: specific version of the
compiler (ie, update 1, etc), full error message including compile line, any
options given to configure, the output of a configure run and the contents of
config.log & autoconf.mk .
Summary: Compilation of src with Sun Workshop 5/6 fails at various points... → Compilation of src with Sun Workshop 6 fails at various points...
> Since you never responded to my request about making sure that nspr was
recompiled from scratch
Ouch... my mistake...
Sorry... ;-(
What's the maximum punishment for this ? ;-(

> (to resolve the question about gcc-specific symbols creeping into the build),

This issue is (hopefully) gone...

> we're going to take this from scratch. 
> Start with a build from scratch. 

Agreed.

> We're going to need the usual info: specific version of the
compiler (ie, update 1, etc), full error message including compile line, any
options given to configure, the output of a configure run and the contents of
config.log & autoconf.mk .

% CC -V
CC: Sun WorkShop 6 2000/08/30 C++ 5.1 Patch 109490-01
% cc -V
cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02
% uname -a
SunOS grendel 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-5_10

Workshop patches installed:
 109478-02 Synopsis: Forte Developer/Sun WorkShop 6: Patch for Debugger
 109480-01 Synopsis: F77 5.1: Patch for Forte Developer 6 F77 5.1 compiler
 109481-03 Synopsis: Compiler Common 6.0: Patch C 5.1, C++ 5.1, F77 5.1, F90 6.0 
 109485-02 Synopsis: F90 6.0: Patch for Forte Development 6 compiler
 109486-02 Synopsis: F90 6.0: Patch for Forte Development 6 compiler
 109490-01 Synopsis: C++ 5.1: Patch for Forte Development 6 C++ compiler
 109491-02 Synopsis: Patch for Forte 6 C 5.1 compiler 

Build of tarball 2000-12-06-08-Mtrunk fails with the following error (gcc 2.95.1
build on the same machine builds OK and works):
% ../configure --with-xprint --enable-mathml --enable-svg --enable-optimize 
--enable-xsl --with-extensions 2>&1 | tee -a buildlog_ws
6.log
[snip]
% make
[snip]
/opt/SUNWspro/bin/CC -library=iostream -o nsAtomTable.o -c -DOSTYPE=\"SunOS5\"
-DOJI -D_IMPL_NS_COM -D_IMPL_NS_BASE   -I../../dist/i
nclude -I../../dist/include     -I/usr/openwin/include   -KPIC  -mt -O  -DDEBUG
-DDEBUG_gisburn -DTRACING -g -DMOZILLA_CLIENT -DBROK
EN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino
-DMOZ_WIDGET_GTK=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_H
EADERS=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 -DHA
VE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_ST
ATFS_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 -D
HAVE_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_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_MAIL_NEWS=1 -DMOZ_ENDER
_LITE=1 -DNS_MT_SUPPORTED=1 -DDETECT_WEBSHELL_LEAKS=1
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_SVG=1 -DMOZ_XSL=1 -DMOZ_DLL_S
UFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1
-DLAYERS=1  ../../../xpcom/ds/nsAtomTable.cpp
"../../../xpcom/ds/nsAtomTable.cpp", line 63: Warning (Anachronism): Formal
argument f of type extern "C" int(*)(PLHashEntry*,int,vo
id*) in call to PL_HashTableEnumerateEntries(PLHashTable*, extern "C"
int(*)(PLHashEntry*,int,void*), void*) is being passed int(*)(
PLHashEntry*,int,void*).
"../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument iter of type
unsigned short**& in call to static nsCharSinkTrait
s<unsigned short*>::write(unsigned short**&, unsigned short*const*, unsigned) is
being passed unsigned short*.
"../../../xpcom/ds/nsAtomTable.cpp", line 144:     Where: While instantiating
"copy_string<nsReadingIterator<unsigned short>, unsign
ed short*>(nsReadingIterator<unsigned short>&, const nsReadingIterator<unsigned
short>&, unsigned short*&)".
"../../../xpcom/ds/nsAtomTable.cpp", line 144:     Where: Instantiated from
non-template code.
"../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument s of type
unsigned short*const* in call to static nsCharSinkTrai
ts<unsigned short*>::write(unsigned short**&, unsigned short*const*, unsigned)
is being passed const unsigned short*.
"../../../xpcom/ds/nsAtomTable.cpp", line 144:     Where: While instantiating
"copy_string<nsReadingIterator<unsigned short>, unsign
ed short*>(nsReadingIterator<unsigned short>&, const nsReadingIterator<unsigned
short>&, unsigned short*&)".
"../../../xpcom/ds/nsAtomTable.cpp", line 144:     Where: Instantiated from
non-template code.
2 Error(s) and 1 Warning(s) detected.
make[2]: *** [nsAtomTable.o] Error 2
make[2]: Leaving directory `/bigtmp/gisburn/mozilla/objdir_ws6/xpcom/ds'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/bigtmp/gisburn/mozilla/objdir_ws6/xpcom'
make: *** [install] Error 2

I'll attach build logs in a few secs...

BTW: --enable-optimize uses "-O"... what about using the WS-specific "-fast" -
this should give much better optimisation... :-)
Roland...I am at the exact same point in this build as you are...im dying with
the nsAtomTable..in xpcom/ds I am on x86 however and not Sparc...so there must
be a compiler issue here on Forte itself and not related to just Sparc or x86. 

# /opt/SUNWspro/bin/CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/12
To quote mozilla/xpcom/ds/nsAtomTable.cpp:
-- snip --
Note: since the |size| will initially also include the |PRUnichar| member
|mString|, our size calculation will give us one character too many. We use that
extra character for a zero-terminator.

Note: this construction is not guaranteed to be possible by the C++ compiler.  A
more reliable scheme is used by |nsShared[C]String|s, see
http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsSharedString.h#174
-- snip --

Stupid question: Is it possible that WS6 does not like that ?

CC'ing scc for c++ conformance issues.

*** Bug 63772 has been marked as a duplicate of this bug. ***
Fixed - Sun Workshop 6 Update 2 EarlyAccess
(http://access1.sun.com/fortedevprod/) compiled mozilla-2001-02-08-08-Mtrunk
without compillation problems and resulting binary works (configure
--with-xprint --enable-mathml --enable-svg --enable-xsl --with-extensions
--enable-optimize="-xO1"; Xlib build not finished yet...).

Note that any optimizer level higher than -xO2 (including "-fast" option - which
is in fact a macro which sets optimizer level to -xO5) causes problems here - at
least Nedit and NCBI blast crash where binaries created with -xO1 do not crash.

Thank you very much - whoever fixed this... :-)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
The silly "libnspr4.so link fails due missing __eprintf symbol" occured again
(mozilla-2001-02-11-08-Mtrunk tarball):
-- snip --
/opt/SUNWspro/bin/CC -library=iostream -o regExport.o -c -DOSTYPE=\"SunOS5\"
-DOJI -DUSE_NSREG   -I../../../dist/include -I../../../dist/include     
-I/usr/openwin/include   -KPIC  -I/usr/local/include -mt -O  -DDEBUG
-DDEBUG_gisburn -DTRACING -g -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\" -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_DIRENT_H=1
-DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_FILIO_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_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_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1
-DNS_MT_SUPPORTED=1 -DCPP_CV_QUALIFIERS_CAUSE_AMBIGUITY=1
-DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_SVG=1
-DMOZ_XSL=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1
-DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 
../../../../xpcom/tools/registry/regExport.cpp
/opt/SUNWspro/bin/CC -library=iostream  -I/usr/local/include -mt -O  -DDEBUG
-DDEBUG_gisburn -DTRACING -g -o regExport regExport.o -xildoff
-L../../../dist/bin -L../../../dist/lib  -L../../../dist/bin -lplds4 -lplc4
-lnspr4 -lpthread -L../../../dist/bin -lxpcom  -lposix4 -lsocket -liostream
-lCrun -ldl -lm    
Undefined                       first referenced
 symbol                             in file
__eprintf                           ../../../dist/bin/libnspr4.so
ld: fatal: Symbol referencing errors. No output written to regExport
make[3]: *** [regExport] Error 1
make[3]: Leaving directory
`/bigtmp/gisburn/mozilla-2001-02-11-08-Mtrunk/mozilla/objdir_ws6_xlib/xpcom/tools/registry'
make[2]: *** [install] Error 2
make[2]: Leaving directory
`/bigtmp/gisburn/mozilla-2001-02-11-08-Mtrunk/mozilla/objdir_ws6_xlib/xpcom/tools'
make[1]: *** [install] Error 2
make[1]: Leaving directory
`/bigtmp/gisburn/mozilla-2001-02-11-08-Mtrunk/mozilla/objdir_ws6_xlib/xpcom'
make: *** [install] Error 2
-- snip --

Build sequence was:
-- snip --
% export CC=/opt/SUNWspro/bin/cc CXX=/opt/SUNWspro/bin/CC CFLAGS="-I/usr/include
-I/usr/local/include" CXXFLAGS="-I/usr/include -I/usr/local/include"
% ../configure --enable-toolkit=xlib --with-xprint --enable-mathml --enable-svg
--enable-xsl --enable-optimize 2>&1 | tee -a buildlog_ws6_xlib.log
% time nice -n 8 make 2>&1 | tee -a buildlog_ws6_xlib.log
-- snip --

Ok... where is eprintf used ?
Checking source:
-- snip --
mozilla-2001-02-11-08-Mtrunk/mozilla% for i in */ ; do echo $i ; done | grep -v
"^objdir" | while read dir ; do echo "#### $dir"; tgrep eprintf $dir ; done
#### CVS/
#### README/
#### build/
#### caps/
#### config/
#### db/
#### dbm/
#### directory/
#### docshell/
#### dom/
#### editor/
#### embedding/
#### expat/
#### extensions/
#### gc/
#### gfx/
#### htmlparser/
#### include/
#### intl/
#### jpeg/
#### js/
#### l10n/
#### layout/
#### lib/
#### mailnews/
#### modules/
#### netwerk/
#### nsprpub/
#### plugin/
#### profile/
#### rdf/
#### security/
#### sun-java/
#### themes/
#### tools/
#### uriloader/
#### view/
#### webshell/
#### widget/
#### xpcom/
#### xpfe/
#### xpinstall/
-- snip --

Checking build dir:
-- snip --
mozilla-2001-02-11-08-Mtrunk/mozilla/objdir_ws6_xlib% tgrep eprintf
./buildlog_ws6_xlib.log :__eprintf                          
../../../dist/bin/libnspr4.so
-- snip --
(buildlog*.log is the output of makefiles&co.)

None of the shared libraries (png|gdk|gtk|idl) references eprintf (because
they're build with Sun Workshop 6U1).

My assumtion are:
a) Somewhere, something is writing into the source dir which makes it impossible
to run builds using different compilers at the same time (currently our system
is compiling five different builds from the same source using different objdir_*
directories - and the last time this happened the same build).
b) Something in the build scripts "imports" (or links) something from
/usr/local/(include|lib) which requires eprintf() (maybe iterfers with [a]).

Uhm... any idea how to get rid of this issue ?
Summary: Compilation of src with Sun Workshop 6 fails at various points... → Compilation of src with "Sun Workshop 6 Update 2 EA" fails at various points...
Switch to using --enable-nspr-autoconf and run your tests from scratch again. 
You didn't show the logs for the nspr build and I suspect that it is still being
built with gcc.  With the classic nspr builds, you can only have one optimized
and one debug build unless you specificly set OBJDIR_NAME for nspr.
I've attached the build log. The only occurence of the string "gcc" is from
"configure" output where it selects the compiler:
-- snip --
% cat buildlog_ws6_xlib.log | grep -i gcc
checking for gcc... /opt/SUNWspro/bin/cc
-- snip --

> You didn't show the logs for the nspr build and I suspect that it is still
being built with gcc.

Uhm, why did a "standalone" build (no other build running at the same time) from
the previous's day tarball work without this problem ?

> With the classic nspr builds, you can only have one optimized and one debug
build unless you specificly set OBJDIR_NAME for nspr.

Why ? Does it write something to the "source" directory or does it store
something in the user's $HOME dir ?

I use the following sequence to creare my builds.
1. Unpack source
2. cd mozilla
# gtk
3a) open new dtterm
4a) mkdir objdir_ws6_gtk; cd objdir_ws6_gtk
5a) set CC/CFLAGS/CXX/CXXFLAGS; ../configure --with-xprint
--turn-other-modules-on
6a) make
# xlib
3b) open new dtterm
4b) mkdir objdir_ws6_xlib; objdir_ws6_xlib
5b) set CC/CFLAGS/CXX/CXXFLAGS; ../configure --enable-toolkit=xlib --with-xprint
--turn-other-modules-on
6b) make
# gcc xlib
3b) open new dtterm
4b) mkdir objdir_gcc_xlib; objdir_gcc_gtk
5b) ../configure --enable-toolkit=xlib --with-xprint --turn-other-modules-on
6b) make

UHm... is there something wring with this procedure ??

> I've attached the build log. 

That build log is useless as it does not show the nspr objs being rebuilt.  

>Uhm, why did a "standalone" build (no other build running at the same time) 
from the previous's day tarball work without this problem ?

A guess is because you didn't clobber your _OPT.OBJ dirs with other builds with
different configurations.

>> With the classic nspr builds, you can only have one optimized and one debug
build unless you specificly set OBJDIR_NAME for nspr.

>Why ? Does it write something to the "source" directory or does it store
something in the user's $HOME dir ?

By design.  Yes, it creates <platform>_(OPT|DBG).OBJ directories in the source
directories.  

> # gtk
> # xlib
> # gcc xlib

It looks like when you create the gcc build, it is rebuilding the NSPR libs
which causes the __eprintf to be pulled in.  Although since NSPR has no
dependency checks, it is possible that NSPR is not rebuilt for each of your
separate builds (assuming that they are all OPT or all DBG) so whether you hit
this problem would depend upon which order you did your builds.
 


It looks like when you create the gcc build, it is rebuilding the NSPR libs
which causes the __eprintf to be pulled in. 

This explanation makes sense...

> Although since NSPR has no dependency checks, it is possible that NSPR is not
rebuilt for each of your separate builds (assuming that they are all OPT or all
DBG) so whether you hit this problem would depend upon which order you did your
builds.

All debug builds...
... nice... ;-(

Is there a way to tell NSPR build to treat all source dirs as READ-ONLY and
store all obj files in objdir_CC_TK ?

When you build mozilla, pass --enable-nspr-autoconf to make nspr build using
configure rather than the classic autoconf build.
Thanks... I read your postings a 2nd time, checked the code and simply tried it
with --enable-nspr-autoconf (/bigsrc is now read-only for the build user. If
something likes to write to that dir --> die hard =:-)
Two parallel builds started... wating for results...
This bug is marked as fixed, but trying to compile the last nightly source
release (31st May) I get the attached errors.  (Mind you, it seems there's
more than one bug included in here.)  This is with

CC: Sun WorkShop 6 2000/08/30 C++ 5.1 Patch 109490-01

configured with:

env CC=cc CFLAGS=-O CXX=CC CXXFLAGS=-O2 ./configure --prefix=/usr/local/mozilla
--with-jpeg=/usr/local --with-zlib=/usr/local --with-png=/usr/local
--with-mng=/usr/local

the first error is:

../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument iter of type
unsigned short*
*& in call to static nsCharSinkTraits<unsigned short*>::write(unsigned short**&,
unsigned short*
const*, unsigned) is being passed unsigned short*.
"nsAString.cpp", line 235:     Where: While instantiating
"copy_string<nsReadingIterator<unsigne
d short>, unsigned short*>(nsReadingIterator<unsigned short>&, const
nsReadingIterator<unsigned 
short>&, unsigned short*&)".
"nsAString.cpp", line 235:     Where: Instantiated from non-template code.
"../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument s of type
unsigned short*con
st* in call to static nsCharSinkTraits<unsigned short*>::write(unsigned
short**&, unsigned short
*const*, unsigned) is being passed const unsigned short*.
"nsAString.cpp", line 235:     Where: While instantiating
"copy_string<nsReadingIterator<unsigne
d short>, unsigned short*>(nsReadingIterator<unsigned short>&, const
nsReadingIterator<unsigned 
"../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument iter of type
unsigned short*
*& in call to static nsCharSinkTraits<unsigned short*>::write(unsigned short**&,
unsigned short*
const*, unsigned) is being passed unsigned short*.
"nsAString.cpp", line 235:     Where: While instantiating
"copy_string<nsReadingIterator<unsigne
d short>, unsigned short*>(nsReadingIterator<unsigned short>&, const
nsReadingIterator<unsigned 
short>&, unsigned short*&)".
"nsAString.cpp", line 235:     Where: Instantiated from non-template code.
"../../dist/include/nsAlgorithm.h", line 76: Error: Formal argument s of type
unsigned short*con
st* in call to static nsCharSinkTraits<unsigned short*>::write(unsigned
short**&, unsigned short
*const*, unsigned) is being passed const unsigned short*.
"nsAString.cpp", line 235:     Where: While instantiating
"copy_string<nsReadingIterator<unsigne
d short>, unsigned short*>(nsReadingIterator<unsigned short>&, const
nsReadingIterator<unsigned 
short>&, unsigned short*&)".
short>&, unsigned short*&)".
"nsAString.cpp", line 235:     Where: Instantiated from non-template code.
"nsAString.cpp", line 235:     Where: Instantiated from non-template code.
2 Error(s) detected.
2 Error(s) detected.
make[2]: *** [nsAString.o] Error 2
make[2]: *** [nsAString.o] Error 2
:
:
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → mozilla0.9.3
"C++ 5.1 Patch 109490-01" is AFAIK _not_ Sun Workshop 6 Update 2 EA2... please
file a new bug for this.

I do not see any issues since three weeks here - except that "--disable-ldap" is
currently required... but that's another bug (bug 78503)...

Marking as "WorksForMe"...
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: