Closed Bug 43826 Opened 24 years ago Closed 22 years ago

Nightly Build failure with workshop 6 (AKA forte6) SPARC

Categories

(Core :: Layout, defect, P2)

Sun
Solaris
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: neel, Assigned: scc)

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 obsolete file)

Workshop6 nigtly builds have been failing for the past 2 days(begining 0623)
with the following error

=====
"nsStyleContext.cpp", line 2035: Error:
"nsStyleContextData::AddRef()" has already been called and cannot
be defined inline.
=====

Machine : ultra1 (sparc)
OS : solaris 2.7
CFLAGS : -O -library=iostream -xarch=v8plus
see also bugs 39730 and 39133
The nightly build has now been failing with the following error
===============
nsAlgorithm.h", line 72: Error: Formal argument iter of type char**&
in call to static nsCharSinkTraits::write(char**&, char*const*,
unsigned) is being passed char*. 
"nsAlgorithm.h", line 72: Error: Formal argument s of type
char*const* in call to static nsCharSinkTraits::write(char**&,
char*const*, unsigned) is being passed const char*. 
2 Error(s) detected. 
================

I am changing the priority of the bug, 'coz we are unable to build mozilla with
workshop6 for the past few weeks.
Severity: normal → blocker
Priority: P3 → P2
Summary: Nightly Build failure with workshop 6 (AKA forte6) → Nightly Build failure with workshop 6 (AKA forte6) SPARC
See also bug 44334.
Reassgning to pierre for futher investigation.
Assignee: clayton → pierre
settinb bug status to new
Status: UNCONFIRMED → NEW
Ever confirmed: true
Neelakanth Nadgir: let me explain you how things work here when a build gets 
broken. It's fairly simple:
1) We fix it on our local machine.
2) We check the fix in.

Alternatively, if you don't have checkin privileges, you can send a patch to the 
programmer whose checkin broke your build. Opening a bug report is the least 
efficient method to deal with build breakages.

I'm closing as WontFix, a bit puzzled by the episode. Don't ask yourself what 
Mozilla can do for you, ask yourself what you can do for Mozilla.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
pierre, what the fuck kind of resolution is that?  this breaks an entire fucking
platform.  this keeps me from being able to run quantify and purify which blocks
me from fixing my nsbeta3+ bugs.  don't resolve build bustage as wontfix.  that
is utter bullshit.
Status: RESOLVED → REOPENED
Keywords: nsbeta3
Resolution: WONTFIX → ---
reassigning since someone doesn't care about some platforms.
Assignee: pierre → pavlov
Status: REOPENED → NEW
I've checked in a fix for the first build problem.  I was seeing this with WS5.

scott?  the other part is in your code.
I won't take no fuck nor bullshit and I hope the reporter will show a little bit 
more sense of responsibilities in the future like any other programmer on the 
project. This bug was reported on 06/26 against a build breakage with an obvious 
fix. Filing a bug report everytime Tinderbox turns red would be completely 
counter-productive, that's why we don't do it.
Although the bonsai-hook mailing list and the build newsgroup are sometimes used
to get build-bustage fixes communicated more quickly, bugzilla is a completely
appropriate mechanism for reporting bugs that cause compile-time errors.  The
reporter did exactly the right thing by filing this bug.  Pierre, in the future,
please reassign legimate bugs such as this one if you are unwilling or unable to
fix them.
Alright, sorry everybody, I stand corrected (but I'm still not taking no fuck nor 
bullshit or at least not in writing in public forums - send them over the phone: 
I always enjoy having a chance to express my love :-P ).

As a more positive contribution to this bug, I humbly suggest to reassign it to 
scc to take care of the bustage in nsAlgorithm.h. If it's urgent, you can also 
send him a patch directly.
I'll take a look at this
Assignee: pavlov → scc
Status: NEW → ASSIGNED
The nsAlgorithm.h portion of this bug looks like a compiler problem at first 
blush.  The compiler has suspiciously gotten the type wrong, adding an extra |*|.  
But wait, this is a partially specialized template --- note the

  template <class CharT>
  struct nsCharSinkTraits<CharT*>

could that be where it got the extra |*|?  I need to know what auto-conf says the 
value of |HAVE_CPP_PARTIAL_SPECIALIZATION| is.  Did workshop pass the test?  If 
so, perhaps the test isn't strong enough.  If not, then I'm barking up the wrong 
tree.

Neelakanth: can you check the value of this auto-conf produced define?  If it is 
_not_ defined, then I need to keep searching.  If it _is_ defined, then we have a 
probable compiler bug.

Should I assign the bug back to you until you determine this?
looking at config/autoconf.mk, ACDEFINES has  -DHAVE_CPP_PARTIAL_SPECIALIZATION=1

all: I am not a c++ guru, but if i was, i would have definetly helped fixing
this bug.
All right, so we may be on the right track.  What happens if you _force_
|HAVE_CPP_PARTIAL_SPECIALIZATION| to be undefined?  If this then allows you to 
build, then we know that you have a compiler bug and we need to fix the partial 
specialization auto-conf test to account for it.
it compiles cleanly if we undefine HAVE_CPP_PARTIAL_SPECIALIZATION
. I tried this with M17 and workshop6
Terrific.  OK, forte6 has a compiler bug in its support for template partial 
specialization.  To account for this, we need to make the autoconf test case for 
|HAVE_CPP_PARTIAL_SPECIALIZATION| stronger.  In the mean time, a temporary fix to 
get you building again is force-undefine this symbol in autoconf, as you have 
demonstrated.  Now the problem is, I'll need access to a machine+compiler that 
exhibits this behavior so that I can fix the test.  Do you have a machine I can 
telnet into?  Or, actually, would it be easier for me to post an exploratory 
patch or two to this bug, that you could apply to the autoconf tests until we can 
get the test to fail?  Perhaps even easier, I'll look for a machine with this 
configuration internally.  I'll ask mcafee and waterson. 
This change also fixes Bug 21138 and Bug 43636 but now I'm getting

CC -library=iostream -o nsStdURL.o -c -DOSTYPE=\"SunOS5\" -DOJI  -I../../../dist
/include        -KPIC  -mt -O  -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -DBROKEN_QSOR
T=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_GTK=1 -DMOZ_DEF
AULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAV
E_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DH
AVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHA
VE_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_LIBRESOLV=1 -DHAVE_LIB
SOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DH
AVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAV
E_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 -DGETTIM
EOFDAY_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_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USIN
G=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_IMPLEMENTATI
ONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUP
PORTED=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_DLL_SUFFIX=\".so\" -DX
P_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1  nsStdURL.cpp
"", line 129: 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: 967)
gmake[3]: *** [nsStdURL.o] Error 199
gmake[3]: Leaving directory `/home/doehrm/mozilla/netwerk/base/src'
gmake[2]: *** [install] Error 2
gmake[2]: Leaving directory `/home/doehrm/mozilla/netwerk/base'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/home/doehrm/mozilla/netwerk'
gmake: *** [install] Error 2

Marcus, that's bug 43626 (your's I believe), and that's a bug in the 
Sun compiler. That's still going to cause Workshop 6 builds to fail
on Solaris Intel.
I deleted (?) after configuring the -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 from 
the config/autoconf.mk file. Now I'm getting this:


CC -library=iostream -o nsIOService.o -c -DOSTYPE=\"SunOS5\" -DOJI  -I../../../d
ist/include        -KPIC  -mt -O  -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -DBROKEN_Q
SORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino -DMOZ_WID
GET_GTK=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DH
AVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -D
HAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DH
AVE_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_LIB
RESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DH
AVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHA
VE_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_GETT
IMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAV
E_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_
SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIG
UITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOT
EQUAL=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 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_DLL
_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1  nsI
OService.cpp
CC: -D option without arguments
SunWS_cache: Error: Error occurred in invoked compiler, exit status = 1(2).  Abo
rting....
gmake[3]: *** [nsIOService.o] Error 1
gmake[3]: Leaving directory `/export/home/doehrm/mozilla/netwerk/base/src'
gmake[2]: *** [install] Error 2
gmake[2]: Leaving directory `/export/home/doehrm/mozilla/netwerk/base'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/home/doehrm/mozilla/netwerk'

[doehrm@sun8 ~/mozilla]$ what `which CC` | egrep -i workshop
        RELEASE VERSION Sun WorkShop 6 2000/04/07 C++ 5.1

[doehrm@sun8 ~/mozilla]$ uname -a
SunOS sun8 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-5_10

Was that wrong DELETING this line? Setting it to '0' does not help...



This -D problem is the one that has blocked me from compiling Mozilla with
Sun C++ v5.0 since early June.  I have just upgraded to C++ v5.1 and should
have a patch from Sun that addresses *that* problem Monday, August 21. I can
supply the patch # to the Sun folk involved in this (it's not yet a public
patch so I can't give it here).
OK, so there's a work-around in place ... and the remaining blocker is bug 43626; 
that means I can mark this bug nsbeta3-.  We'll still get around to fixing the 
autoconf test, though.
Whiteboard: [nsbeta3-]
I'm just curious if there are any news on this compiler 'bug'... 
We are using Gnu compilers for our Solaris Netscape 6 release, and have
not dealt with the Sun compiler group for 2-3 months, so I have no idea
on the status of this patch. Neel, you've been working with the Sun compilers
group to try to build Mozilla. Is there anything that interested developers
can do to get a version of the Forte compiler that's capable of building
latest Mozilla?
The Sun C++ compiler team assures me that the latest version of Forte Developer
(6 Update 1) compiles mozilla cleanly. I havent tried it out. If anybody is
interested in trying it out, please send me an email, I will be glad to ship you
a CD and a demo license.
I assume you mean patch 109490-01 and 109491-02? I'll try this this evening.
I'm getting now a weired error:

gmake[2]: Entering directory `/export/home/doehrm/mozilla/xpfe/bootstrap'
CC -library=iostream -o mozilla-bin -mt -O  -DNDEBUG -DTRIMMED -DWIDGET_DLL=\"li
bwidget_gtk.so\" -DGFXWIN_DLL=\"libgfx_gtk.so\" -I/opt/sfw/lib/glib/include -I/o
pt/sfw/include     nsAppRunner.o nsSetupRegistry.o nsSigHandlers.o   -xildoff -L
../../dist/bin -L../../dist/lib -Qoption ld -z,allextract -lxpfelocation_s -lmpf
ilelocprovider_s   -lgkgfx -L../../dist/bin -lxpcom -lmozjs -ljsj -lplds4 -lplc4
 -lnspr4 -lpthread  -lw -lposix4 -lintl -lelf -lnsl -lsocket -lresolv -liostream
 -lCrun -ldl -lm
ld: fatal: symbol `__copyright' is multiply defined:
        (file /opt/SUNWspro/WS6/lib/libiostream.a(release.o) and file /opt/SUNWs
pro/WS6/lib/libCstd.a(release.o));
ld: fatal: File processing errors. No output written to mozilla-bin
gmake[2]: *** [mozilla-bin] Error 1
gmake[2]: Leaving directory `/export/home/doehrm/mozilla/xpfe/bootstrap'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/home/doehrm/mozilla/xpfe'
gmake: *** [install] Error 2

It really seems to be compiler specific. Since I don't have access to sunsolve 
actually (network problem) could someone @Sun please do a quick search?
Are you sure you are not mixing standard iostreams with classic iostreams? i.e 
are all objects built with -library=iostreams ?
Another workaround, though ugly is to convert libiostream.a into libiostream.so.
let me know if you have further problems.
Please apologize, but how to check this? Since I didn't write the output into a 
logfile, I cannot check. As far as I remember, I always saw CC -
library=iostream but I can't prove.

Conversion: How do I convert a static library in a shared one (without having 
the sources)?
OK, here is how i build it. I set CFLAGS="-library=iostreams" and then
configure. this always works for me.
To convert a .a to a .so, use CC -G -Kpic -o foo.so foo.a
Ok, getting the following:

doehrm@sun8 ~/mozilla]$ CC=cc CXX=CC  ./configure --disable-debug --enable-opti
mize --enable-mathml --enable-svg --disable-tests
loading cache ./config.cache
checking host system type... sparc-sun-solaris2.8
checking target system type... sparc-sun-solaris2.8
checking build system type... sparc-sun-solaris2.8
checking for gcc... (cached) cc
checking whether the C compiler (cc -library=iostreams ) works... no
configure: error: installation or configuration problem: C compiler cannot creat
e executables.

[doehrm@sun8 ~/mozilla]$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:769: checking host system type
configure:790: checking target system type
configure:808: checking build system type
configure:1795: checking for gcc
configure:1908: checking whether the C compiler (cc -library=iostreams ) works
configure:1924: cc -o conftest -library=iostreams   conftest.c  1>&5
ld: fatal: library -library=iostreams: not found
ld: fatal: File processing errors. No output written to conftest
configure: failed program was:

#line 1919 "configure"
#include "confdefs.h"

main(){return(0);}

Am I silly? (sorry, must be _very_ basic...)
Ok, the problem seems to be fixed with Update-1 of Forte 6/5.1.

I'm writing this on a mozilla compiled with forte on sparc.

:-)
Current state:

I installed a new machine with SunOS 5.8/SPARC/Forte6U1 and MU2 one with SunOS 
5.8/INTEL/Forte6U1.

The build on Sparc works currently, the build on Intel doesn't. I builds fine 
with the following configuration:

[doehrm@wwwpits ~/mozilla/dist/bin]$ cc -V
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/12

[doehrm@wwwpits ~/mozilla/dist/bin]$ grep -i update /etc/release
                     Solaris 8 Maintenance Update 3 applied

[doehrm@wwwpits ~/mozilla/dist/bin]$ cat ~/.mozconfig
mk_add_options  MOZ_CVS_FLAGS=-q

ac_add_options  --disable-tests
ac_add_options  --disable-debug

I'm doing the build with 'CC=cc CXX=CC gmake -f client.mk'

The build runs fine without optimization, however, after starting the app 
sigsegv:

<snip>
RegSelf Unicode to IBM857 converter complete
RegSelf Unicode to IBM862 converter complete
RegSelf Unicode to IBM864 converter complete
Segmentierungsfehler - Speicherabbild 'core' geschrieben

(dbx) where
=>[1] PL_HashTableEnumerateEntries(0x8188580, 0xdf9e4340, 0x0), at 0xdf8614f0
  [2] nsHashtable::Reset(0x8188578, 0x0, 0x0), at 0xdf9e4479
  [3] nsHashtable::Reset(0x8188578, 0x8045a50, 0x8045e48, 0x8045a4b, 0x0, 0x8158
ec8, 0x8045e20), at 0xdf9e43fe
  [4] nsXPCWrappedNativeClass::CallWrappedMethod(0x8182ff0, 0x8188578, 0x8184160
, 0x815cf3c, 0x1, 0x0, 0x0, 0x80462d4), at 0xdf4b0dcf
  [5] WrappedNative_GetProperty(0x8188578, 0x8158ec8, 0x815e0e0, 0x80462d4), at
0xdf4b32bb
  [6] js_Interpret(0x8188578, 0x804660c), at 0xdf91ff4c
  [7] js_Execute(0x8188578, 0x8158eb8, 0x81b08c0, 0x0, 0x0, 0x804660c), at 0xdf9
168e9
  [8] JS_ExecuteScript(0x8188578, 0x8158eb8, 0x81b08c0, 0x804660c), at 0xdf8e729
a
  [9] mozJSComponentLoader::GlobalForLocation(0x8163590, 0x8151358, 0x8163620),
at 0xdf4492a1
  [10] mozJSComponentLoader::ModuleForLocation(0x8163590, 0x8151358, 0x8163620),
 at 0xdf447e39
  [11] mozJSComponentLoader::AttemptRegistration(0x8163590, 0x8163620, 0x0), at
0xdf446f38
  [12] mozJSComponentLoader::AutoRegisterComponent(0x8163590, 0x0, 0x8163620, 0x
8046bd8), at 0xdf446b17
  [13] mozJSComponentLoader::RegisterComponentsInDir(0x8163590, 0x0, 0x807c628),
 at 0xdf44620b
  [14] mozJSComponentLoader::AutoRegisterComponents(0x8163590, 0x0, 0x807c628),
at 0xdf445fb2
  [15] AutoRegister_enumerate(0x8160350, 0x8163590, 0x8047360), at 0xdfa64b31
  [16] _hashEnumerate(0x816a000, 0x1, 0x8046d10), at 0xdf9e3bc7
  [17] PL_HashTableEnumerateEntries(0x807a3d8, 0xdf9e3b80, 0x8046d10), at 0xdf86
1500
  [18] nsHashtable::Enumerate(0x807a3d0, 0xdfa64ad0, 0x8047360), at 0xdf9e4327
  [19] nsComponentManagerImpl::AutoRegisterImpl(0x80774d0, 0x0, 0x0), at 0xdfa65
ecf
  [20] nsComponentManagerImpl::AutoRegister(0x80774d0, 0x0, 0x0), at 0xdfa64c66
  [21] nsComponentManager::AutoRegister(0x0, 0x0), at 0xdfa73246
  [22] NS_AutoregisterComponents(), at 0x805bb82
  [23] NS_SetupRegistry_1(0x1), at 0x805bcbc
  [24] main1(0x1, 0x8047a70, 0x0), at 0x8058bcf
  [25] main(0x1, 0x8047a70, 0x8047a78), at 0x805b06f

The non-optimized debug compile does also sigsegv.

With optimization enabled (--enable-optimize) the build fails at 
js/src/jsinterp.c (see Bug 43626).

So does anyone have an idea what's happening here? 
Attachment #12160 - Attachment is obsolete: true
I'm not sure I get it, is this bug just used for dumping general problems on
this platform? Is it still a blocker?
hwaara: this isn't unusual, the reason to recycle a build failure bug for a 
special os/compiler is because you've already collected a useful CC list.

i have solaris8intel here, i suppose i could get the SunONE trial for it and 
try building (in vmware). -- I'll try to look into that sometime this month.
I havent built the nightly builds recently, but "it should work". The sun
compiler team builds mozilla as a part of the their nightly QA. If it doesnt
build, plz let  me know so that i can pass it along.
there seem to be no recent open concerns.  closing this bug accordingly
Status: ASSIGNED → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: