28817 - Solaris/Intel/WS5.0: missing xptcinvoke_asm_x86_soalris.s

Status: RESOLVED FIXED

Description

[amarzec]

xptcinvoke_asm_x86_soalris.s is missing
xptcstubs_asm_X86_solaris.s is missing
Can you just use ansi c for this functionality???
I use a sun workshop compiler 5.0 for X86 and
dont have a clue how to manipulate the program
stack as you do with gcc.
Would it not carry you a lot further in to
find a good way of producing this code in ansi C.
I applaud the cleverness of the writers on makeing this code
only were does it leave the rest of us not so bright ones.
Even if you know its slower if it at least works thats all anyone
would ask.
Thanks for your kind attention

Comment 1

[Chris Waterson]

porting issue. jband, i really hate to dump this on you, but, i'm not sure where 
else to put it.

Comment 2

[John Bandhauer]

If it could be done in C then we would have _very_ happily done it that way.
See: http://www.mozilla.org/scriptable/xptcall-faq.html

Shaver is still the man for xptcall on 'nix porting issues (until he says 
otherwise). I'm also cc'ing mcafee and rogerl because I think this may have come 
up before and I have no idea what the resolution was.

Comment 3

[Chris McAfee]

Better summary.
We probably just need some makefile magic to
pull in the assembly for this compiler case.
I think egcs intel build is working.?

Comment 4

[Rich Burridge]

[richb - 5/4/00]
Mozilla (M15 - the one I tried) compiles and runs happily on Solaris Intel
2.6 (the O/S I tried) when built with the Gnu compilers.

When you try to compile with Sun Workshop compilers, you will get something
like:

"xptc_platforms_unixish_x86.h", line 85: Warning: #error "need a platform define
if using unixish x86 code".
"xptc_platforms_unixish_x86.h", line 91: Warning: #error "need to define 'this'
adjust scheme".
"xptcinvoke_unixish_x86.cpp", line 121: Error: __asm__ is not defined.
"xptcinvoke_unixish_x86.cpp", line 148: Error: Unexpected ":" found.
"xptcinvoke_unixish_x86.cpp", line 161: Warning: The variable result has not yet
been assigned a value.
2 Error(s) and 3 Warning(s) detected.

There are similar errors with the assembly code in xptcstubs_unixish_x86.cpp

"__asm__" is a gcc keyword.  For Sun's native compilers you should use "asm"
keyword instead of "__asm__".

gcc manual recommends to check __GNUC__ macro to determine if  
gcc compiler used:

#ifndef __GNUC__
#define __asm__ asm
#endif

"__volatile__" is also gcc keyword. It means the same as Sun's native compilers 
"volatile".

Files xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp are good 
examples of using gcc compiler's "extended asm" feature but Sun's compilers 
do not support it. These two files need to be rewritten so that they will
work with either compiler.

If common assembler cannot be written, then we will need to do the same
Makefile trickery that the SPARC assembly files need for Gnu vs SW 5.0
compilers.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Actually, I think GCC accepts the underscore-less (``asm'' and ``volatile'')
variants as well, so that much at least can be shared.

I don't know enough about either GCC or SunW assembly syntax to help with
developing shared code beyond that, unfortunately.

Comment 6

[Rich Burridge]

[richb - 5/4/00]
We've got a Russian engineer attempting to build M15 (and the three other
libraries that it needs). He hopefully will be able to evaluate how hard
this is to fix. As the ways of the lizard are unknown to him at the moment
this might take a few more days. I'll update this bug when I have more info.

Comment 7

[Rich Burridge]

[richb - 5/12/00]
Looks like there is another problem in getting a Solaris Intel version working
with Sun Workshop compilers. In .../mozilla/configure.in, at line 887, there is:

NS_USE_NATIVE=1

and in .../mozilla/js/src/Makefile.in, at line 153, there is:

ifdef NS_USE_NATIVE
ASFILES     = $(notdir $(wildcard $(srcdir)/*_$(OS_ARCH).s))
endif

Unfortunately the assembly code in lock_SunOS.s in that directory is SPARC
specific.

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Can you report another bug for the js/src problem, so that it can be properly
assigned?

Comment 9

[Rich Burridge]

[richb - 5/14/00]
Mike, just get bug 4575 reopened.

Comment 10

[Rich Burridge]

Created attachment 8736 [details]
.tar.gz of two modified (incomplete) assembler files for Solaris Intel platform with Sun compilers.

Comment 11

[Rich Burridge]

[richb - 5/16/00]
I (and the Russian engineer) are not going to have time to work on this again 
for a while, so I'm going to pass on what we've got. 

Note that at present, if you compile Mozilla on the Solaris Intel platform
with the Gnu compilers, everything works fine. This is an attempt to try
to get the Solaris Intel version of Mozilla to work with both the Gnu and
Sun native compilers.

The previous .tar.gz attachment contains two files:

xptcinvoke_unixish_x86.cpp
xptcstubs_unixish_x86.cpp

If you look at them, you will see that there is an #if 1 around the assembler
code. According to the Russian engineer, this version of the assembly code (
as opposed to the previous Gnu specific code which is in the #else part of
the #if/#endif statement), "should" work with both compilers (Gnu and Sun).
It certainly compiles with both (I was building the M15 milestone).

When the version build with Sun Workshop 5.0 compilers is run, here is the
output (no existing ~/.mozilla directory):

jmqpc1[203] ./mozilla
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin
 
LD_LIBRARY_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin:/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/dist/lib:/usr/openwin/lib:/usr/motif/lib
      
SHLIB_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin
         
LIBPATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Segmentation Fault - core dumped
jmqpc1[204] dbx mozilla-bin core
Reading mozilla-bin
core file header read successfully
Reading ld.so.1
Reading libraptorgfx.so
Reading libmozjs.so
Reading libxpcom.so
Reading libjsj.so
Reading libplds4.so
Reading libplc4.so
Reading libnspr4.so
Reading libpthread.so.1
Reading libraptorwebwidget.so
Reading libdocshell.so
Reading libjsdom.so
Reading libw.so.1
Reading libposix4.so.1
Reading libintl.so.1
Reading libelf.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libresolv.so.2
Reading libCrun.so.1
Reading libdl.so.1
Reading libm.so.1
Reading libthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmp.so.2
Reading libxpinstall.so
detected a multithreaded program
t@0 (l@1) terminated by signal SEGV (no mapping at the fault address)
Current function is nsServiceManagerImpl::GetService
  306                   NS_ADDREF(service);		// Released in service manager
destructor
(dbx) where
  [1] 0xdfbe45fa(0x80631f8), at 0xdfbe45f9
=>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID =
STRUCT, result = 0x80474f4, shutdownListener = (nil)), line 306 in
"nsServiceManager.cpp"
  [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result =
0x80474f4, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp"
  [4] nsGetServiceByCID::operator()(this = 0x80475b4, aIID = STRUCT,
aInstancePtr = 0x80474f4), line 43 in "nsServiceManager.cpp"
  [5] nsCOMPtr_base::assign_from_helper(this = 0x80475c4, helper = CLASS, iid =
STRUCT), line 65 in "nsCOMPtr.cpp"
  [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x80475c4, helper = CLASS),
line 527 in "nsCOMPtr.h"
  [7] main1(argc = 1, argv = 0x80476f4, splashScreen = (nil)), line 652 in
"nsAppRunner.cpp"
  [8] main(argc = 1, argv = 0x80476f4), line 879 in "nsAppRunner.cpp"
(dbx)

When I build the M15 milestone with the Gnu compilers, and with these two
new files containing the modified assembler code, and then run it, I get:
jmqpc1[152] ./mozilla
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin
 
LD_LIBRARY_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin:/net/portal/export1/ENG_WORKSPACES/richb/local-i386/lib:/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/dist/lib:/usr/openwin/lib:/usr/motif/lib
      
SHLIB_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin
         
LIBPATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nsNativeComponentLoader: autoregistering begins.
*** Registering nsTimeBomb components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
nsUnixToolkitService: Using 'gtk' for the Widget Toolkit.
nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit.
NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so,
GFX_DLL=libgfx_gtk.so
initialized appshell
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
DEBUG BUILDS ONLY:  we are forcing you to use the profile manager to help smoke
test it.
Profile Manager : Command Line Options : End
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24
WEBSHELL+ = 1
Segmentation Fault - core dumped

Would you believe that I've been unable to find a version of gdb compiled
for the Solaris Intel platform (for Solaris 2.6 anyway). 

There is one more thing to note about the assembly code. The Russian
engineer introduce an #ifdef for position independent code 
(#if POSITION_INDEPENDENT_CODE) which I don't believe exists. If/when this
ever works, then this might need to be propagated through the configure.in
file.

Perhaps someone more knowledgeable in x386 assembler can take this further.

Comment 12

[Rich Burridge]

[richb - 5/18/00]
I've just found bug 16114 (filed under Windows NT, so I'd missed it), that
included yet another set of assembler code that might work for both compilers.
Something more to try.

Comment 13

[Rich Burridge]

We have a fix for this, but at the moment it's in two hacked up files
(xptcstubs_unixish_x86.cpp xptcinvoke_unixish_x86.cpp) that are Sun
compiler specific. I need to merge these changes with the existing versions
of these files.  Probably early next week...

All the kudo's should go to Bill Taylor, who works for Sun in L.A. It's
nice to know there is now one more person in the world who understands
this code. ;-)

Comment 14

[Rich Burridge]

Created attachment 10284 [details] [diff] [review]
Diffs to get the two files containing the inline Solaris Intel assembler to build/run for both Gnu and Sun native compilers.

Comment 15

[Rich Burridge]

I've just attached diffs to xptcinvoke_unixish_x86.cpp and
xptcstubs_unixish_x86.cpp that build/run with both the Gnu compiler and
the Sun Workshop 5.0 compiler (in optimized mode).

I'm being explicit about the compiler status, because I still
need to determine if the files will work correctly with debug
turned on. I'm going to try this next week. Comments from Bill Taylor
(included below) suggest that they might not work with the 5.0 compiler,
but will work with 5.1 (aka Workshop 6, aka Forte). 

"> Would you expect your asm changes to work if Mozilla was compiled with
 > debug on, or without optimization (ie. no -g and no -O)?

 My first thought was "sure".  After more thinking, I'm not confident.

 There is one tricky thing about the call to invoke_copy_to_stack().
 After it returns, we might have to explicitly set %esp.  Since
 that function is declared static, the generated code need not follow
 the standard ABI calling conventions.  And, it does NOT do so in this
 case (callee pops args).   This could be different with -g, and that
 could break.  The more I think about this, it might be difficult to
 code set %esp properly if this does vary.  This is the only problem
 I can think of might happen."

Note also that Bill dramatically simplified the invoke_count_words() and
invoke_copy_to_stack() routines in xptcinvoke_unixish_x86.cpp. I'd 
appreciate comments on this. It seems to run okay, and the code looks okay, 
but I wonder why this simplication wasn't in the original code.

Same for the switch statement near the end of the PrepareAndDispatch()
method in xptcstubs_unixish_x86.cpp

Comment 16

[Rich Burridge]

As an experiment, I decided to see what would happen if I compiled up
everything with -g. The Gnu version (v2.95.2) works fine, and as expected
from Bill Taylor's last comments, the Sun Workshop 5.0 one has problems. 
It segv's at:

t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 
0xdfbe428a
0xdfbe428a: __RTTI__1CpknKnsObserver_+0x066e:	imull  
$0x636e692f,%fs:116(%ebx),%esi
Current function is nsServiceManagerImpl::GetService
  306                   NS_ADDREF(service);		// Released in service 
manager destructor
(/usr/dist/share/devpro_i386,v5.0/5.x-i386/bin/dbx) where
current thread: t@1
  [1] 0xdfbe428a(0x80631f8), at 0xdfbe4289
=>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID = 
STRUCT, result = 0x8047444, shutdownListener = (nil)), line 306 in 
"nsServiceManager.cpp"
  [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result = 
0x8047444, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp"
  [4] nsGetServiceByCID::operator()(this = 0x8047504, aIID = STRUCT, 
aInstancePtr = 0x8047444), line 43 in "nsServiceManager.cpp"
  [5] nsCOMPtr_base::assign_from_helper(this = 0x8047514, helper = CLASS, iid = 
STRUCT), line 65 in "nsCOMPtr.cpp"
  [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x8047514, helper = CLASS), 
line 527 in "nsCOMPtr.h"
  [7] main1(argc = 1, argv = 0x8047644, splashScreen = (nil)), line 652 in 
"nsAppRunner.cpp"
  [8] main(argc = 1, argv = 0x8047644), line 879 in "nsAppRunner.cpp"

This was expected, and is due to a compiler bug in the SC5.0 Intel compiler.
Here's some comments that Bill sent me earlier in the week:

"With Mike Walker's help, we have identified a C++ compiler bug.
This code was built with "-g".  The first thing to do is try "-O".
Also, it may be worth considering the use of newer/better compilers
that Workshop 5.0.  (Rich is rebuilding with -O now).

The first problem we ran into and identfied is in libxpinstall.so.
A thunk within it has been called by a function in a different
shared object, namely libxpcom.so.  The thunk computes the GOT
for libxpinstall, then restores ebx with the GOT for libxpcom
prior to branching to the PLT.  That is the problem."

What I now need to do is find out if it's still a problem with -g
with the latest version of the compiler (ie SC5.1, Workshop 6, Forte).

Comment 17

[Rich Burridge]

Those diffs to xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp
work fine with Workshop 6 on Solaris Intel (compiled with -O). I've also
successfully build the M16 source tarball on Linux (which also uses
these two files).

I'm now about to try Workshop 6 on Solaris Intel (compiled with -g).

Could somebody review the diffs please? I'd like to see if they can be
checked in this week if I can get an r= and an a=. Thanks.

Comment 18

[Rich Burridge]

The other part of this problem is the fact that configure.in is setting
NS_USE_NATIVE incorrectly for the Solaris Intel platform if the Sun native
compiler is being used. NS_USE_NATIVE  seems to only be used in
.../mozilla/js/src/Makefile.in (and therefore in 
.../mozilla/js/src/Makefile when it's created).

Here's a diff that fixes that problem.

stard[305] diff -c configure.in.orig configure.in
*** configure.in.orig	Tue Jun 20 09:18:05 2000
--- configure.in	Tue Jun 20 09:18:36 2000
***************
*** 901,909 ****
         AR_FLAGS='-o $@'
         AS='/usr/ccs/bin/as'
         AS_DASH_C_FLAG=''
-        NS_USE_NATIVE=1
         case $OS_TEST in
           sun4u)
             ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K 
PIC'
             AC_DEFINE(ULTRA_SPARC)
             ;;
--- 901,909 ----
         AR_FLAGS='-o $@'
         AS='/usr/ccs/bin/as'
         AS_DASH_C_FLAG=''
         case $OS_TEST in
           sun4u)
+            NS_USE_NATIVE=1
             ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K 
PIC'
             AC_DEFINE(ULTRA_SPARC)
             ;;
stard[306]

It will now only set NS_USE_NATIVE if we are on the sun4u Solaris platform,
(ie. SPARC platform,) and we are not using the Gnu compiler.

Comment 19

[Markus Doehr]

I tested the patch on a SunOS 5.8_x86 with Workshop/Forte 6.0; the build works 
fine.

Comment 20

[Rich Burridge]

Created attachment 10449 [details] [diff] [review]
CVS diffs to get Mozilla to build/run on the Solaris Intel platform with the native Sun compilers

Comment 21

[Rich Burridge]

I now have a set of diffs that work. They apply to four files:

.../mozilla/configure.in

This change only sets NS_USE_NATIVE=1 if we are using the native compiler
on the Solaris SPARC platform, not the Solaris Intel platform. This is
used by the Makefile in ...mozilla/js/src/ , to add the assembler file
lock_SunOS.s to the build targets. This file is SPARC assembly code so
shouldn't be used on the Solaris Intel builds.

.../mozilla/xpcom/reflect/xptcall/src/md/unix/Makefile.in

This change forces the following two platform specific files to always
be built with -O. The assembly code in those files, when used with the
Sun native compilers on the Solaris Intel platform, will only work when
compiled optimized.

.../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp
.../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubse_unixish_x86.cpp

These changes now allow Mozilla to be built and run with both the Gnu
compilers and the Sun native compilers on the Solaris Intel platform. 
#ifdef __GNUC__ clauses have been added to differentiate the two cases.

This has been tested with both SC5.0 and SC5.1 (aka Workshop 6, aka Forte)
Sun compilers.

The patch has also been tested on RedHat Linux 6.1 with the Gnu compilers
to make sure Gnu support on other platforms hadn't been broken.

Comment 22

[Thomas Stromberg]

Patch appears to compile fine on FreeBSD 5.0 w/ autoconf 2.14 and gmake 3.79

Comment 23

[Rich Burridge]

Created attachment 10470 [details] [diff] [review]
Small adjustment to the config/build diffs as suggested by cls.

Comment 24

[Rich Burridge]

I've made a small adjustment to the diffs as suggested by cls.
It now uses:

ifndef GNU_CC
OS_CXXFLAGS += -O
endif

rather than:

ifneq ($(CC),gcc)
OS_CXXFLAGS += -O
endif

so that it still works when CC is set using a full path. Thanks cls!

Comment 25

[Rich Burridge]

Created attachment 10500 [details] [diff] [review]
Added in suggestions from mccabe and brendan

Comment 26

[Rich Burridge]

I've just added another attachment with the following refinements suggested
by mccabe and brendan:

* In xptcinvoke_unixish_x86.cpp, I've added the following XXX: comment block:

/* XXX: the following line is here (rather than as the default clause in
 *      the following switch statement) so that the Sun native compiler
 *      will generate the correct assembly code on the Solaris Intel
 *      platform. See the comments in bug #28817 for more details.
 */

* In xptcinvoke_unixish_x86.cpp, and in xptcstubs_unixish_x86.cpp, the 
  assembler for the Sun compiler is now inside a #else if defined(__SUNPRO_CC)
  block, and there is also a #else block also with an #error directive.

I've retested these changes on Solaris Intel with SC5.0 and on RedHat 6.1
Linux with the Gnu compilers, and they build and run just fine.

Comment 27

[Rich Burridge]

Fix checked in; r=[e-mail]  a=[e-mail]

Comment 28

[Markus Doehr]

Is that only valid for M15? I'm getting (strange) errors with the tip of the 
tree:

CC -library=iostream -o nsDirectoryIndexStream.o -c -DOSTYPE=\"SunOS5\" -DOJI  -
I../../../dist/include -I../../../include        -KPIC  -mt -O  -DNDEBUG -DTRIMM
ED -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d
_ino -DMOZ_WIDGET_GTK=1 -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 -DHA
VE_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_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_LOCALT
IME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=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 -DHAV
E_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 -DMO
Z_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DMOZ_USER_DIR=\".mozilla\"
 -DMOZ_MATHML=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THR
EADSAFE=1 -DLAYERS=1  nsDirectoryIndexStream.cpp
"", line 116: Error: String/char constants may not include line separator.
** Assertion ** : 0 (/set/taz/builds/fcs0406/intel-S2/lang/cafe/resources/cdr/sr
c/c_dataparse.cc: 963)
make[4]: *** [nsDirectoryIndexStream.o] Error 195
make[4]: Leaving directory `/home/doehrm/mozilla/netwerk/base/src'
make[3]: *** [install] Error 2
make[3]: Leaving directory `/home/doehrm/mozilla/netwerk/base'

[doehrm@sun8 ~/mozilla]$ uname -a
SunOS sun8 5.8 Generic i86pc i386 i86pc

Comment 29

[Rich Burridge]

doehrm, my tests were indeed done against M15 (as you well know ;-).
Please file a separate Bugzilla bug for the tip-of-the-tree build
problems you are seeing in trying to build the Solaris Intel version
with the Sun Workshop compilers. Thanks.

Comment 30

[John Bandhauer]

I actually would rather that the switch statement simplifications had not been 
made. The cases were explicily layed out as much for documentation of all the 
possible cases to handle and as example for other ports as for any other reason. 
I doubt that the code size or speed was significantly improved by the change. 
But this is no big deal.