Compiler Assertion when trying to link with Forte 6 C++

This is a rather large module, and was compiling and linking just fine until today when some minor code changes went in. Now I get this every time it gets to the linking phase:

/export1/forte6/SUNWspro/bin/CC -w -G -PIC -mt -DRW_MULTI_THREAD -o /export1/etdev3/libs/solaris-sparc/Debug/libecrs.so ecAssociation.o ecAssociationImp.o ecAssociationRef.o ecAttribute.o ecAttributeImp.o ecBooleanData.o ecBooleanDataType.o ecCommon.o ecData.o ecDateData.o ecDateDataType.o ecDataMaker.o ecDebugOut.o ecDoubleData.o ecDoubleDataType.o ecEnum.o ecEnumData.o ecEnumDataType.o ecEnumImp.o ecException.o ecFloatData.o ecFloatDataType.o ecGUIDManager.o ecGUIDManagerUnix.o ecHistoryItem.o ecIntegerData.o ecIntegerDataType.o ecLongData.o ecLongDataType.o ecMetaAssociation.o ecMetaAssociationImp.o ecMetaAttribute.o ecMetaAttributeImp.o ecMetaBaseClass.o ecMetaDataType.o ecMetaMethod.o ecMetaMethodImp.o ecMetaObject.o ecMetaObjectImp.o ecMetaObjectProperty.o ecMetaObjectPropertyImp.o ecMetaParameter.o ecMetaParameterImp.o ecMetaRole.o ecObject.o ecObjectContainer.o ecObjectData.o ecObjectDataType.o ecObjectImp.o ecObjectInstance.o ecObjectInstanceImp.o ecObjectRef.o ecObjectRefData.o ecParameterList.o ecRepository.o ecRepositoryException.o ecRepositoryImp.o ecRepositoryHeader.o ecRepositoryHeaderImp.o ecRepositoryMgr.o ecRepositoryMgrImp.o ecRepositoryObject.o ECRS.o ecRuntimeClass.o ecShortData.o ecShortDataType.o ecSmartObject.o ecStream.o ecStreamException.o ecStreamImp.o ecString.o ecStringData.o ecStringDataType.o ecTable.o ecTableImp.o ecTableDef.o ecTableInstance.o ecTableInstanceImp.o ecTaskItem.o ecUIntegerData.o ecUIntegerDataType.o ecULongData.o ecULongDataType.o ecUNC.o ecUShortData.o ecUShortDataType.o UpdateDataTypes.o FLT/ecStreamFLT.o XML/ecXMLFile.o XML/ecXMLHandler.o XML/ecXMLRepositoryHandler.o CM/ecRepositoryCM.o CM/ecRepositoryMgrCM.o CM/ecStreamCM.o ZLIB/ecStreamZLib.o

** Assertion ** : which_cache != 0 (/set/taz/builds/fcs0406/sparc-S2/lang/cafe/resources/cdr/src/c_filecache.cc: 74)

Exit 74

There are no errors during compilation. I have tried removing the SunWS_Cache directory, making clean, etc. It won't go away.

What causes this? Any idea? Is there a patch to fix this?

For what it's worth, this is on an UltraSparc 10, running Solaris 2.6. The Forte 6 compiler is installed, and this is all C++ code.

[2393 byte] By [michaelvEDI] at [2007-11-25 23:41:49]
# 1
I have exactly the same problem under Sol 2.7.truss reveals an unlink("CC_lock") when no CC_lock file is created. :(May be this compiler works http://www.kai.com
NoeS at 2007-7-5 18:49:21 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

You get the which_cache!=0 assertion when you run a WorkShop 6 (5.0) compiler, directing the .o into a directory where a later compiler had previously run. Are there both WorkShop 6 (5.0) and Workshop 6 update 1 (5.1) compilers used on the system?

The C++ Readme says

<pre>

1. Cache Version Differences May Cause Compilation Errors

</pre>

<pre>

When upgrading compilers, it is always good practice

to run CCadmin -clean on every directory that contains a

SunWS_cache subdirectory (alternately, you can use rm -rf

SunWS_cache). Failure to do so can result in compilation

errors such as the following:

</pre>

<pre>

o SunWS_cache: Error: Database version mismatch

<path>/SunWS_cache/CC_version.

</pre>

<pre>

o "<path>/SunWS_cache/CC_state",

line 3: Error: "" not allowed here.

** Assertion ** : 0

</pre>

Note: when you do CCadmin -clean or rm -rf SunWS_cache, make sure you

are in the same directory where you created (not moved) the objects.

Note: The -ptr option is no longer valid. In WorkShop 6 it was a noop.

In WorkShop 6 update 1, it is outright rejected.

If you use -ptr to direct the .o file, it won't work, and a .o created by a 5.0 compiler might wind up in an unexpected place, where a 5.1 compiler had been run.

Another possibility is that the build process does not use the same

compiler in all steps. This can happen in builds where a needed macro was not passed down from a parent to a child makefile, and different compilers participated in a single build.

ckutler at 2007-7-5 18:49:21 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3
... And make sure you link, using the _same_ compile options!
dragiev at 2007-7-5 18:49:21 > top of Java-index,Development Tools,Solaris and Linux Development Tools...