quantlib-dev

[Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Hi,

I am trying to compile Quantlib on SUN Solaris 10 using SUN CC (I tried
v5.7, v5.8 and v5.10, btw...)

Appearantly the SUN compiler is somehow missing operator== implementations
for e.g. ExchangeRateManager, because I get the following error:

libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
-I/home/spenglan/local/include/boost-1_38
-erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
-KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
-library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
-Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o

"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list.cc", line 173: Error,
badbinaryop: The operation "QuantLib::ExchangeRateManager::Entry == const
QuantLib::ExchangeRateManager::Entry" is illegal.
"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
Where, temwhileinst: While instantiating
"std::list<QuantLib::ExchangeRateManager::Entry>::remove(const
QuantLib::ExchangeRateManager::Entry&)".
"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
Where, teminstend: Instantiated from non-template code.
1 Error(s) detected.

Perhaps I am using a bad compiler switch.

When I add an operator== in Quantlib::ExchangeRateManager::Entry (doing
memberwise comparison), I get the same error above for
Quantlib::ExchangeRateManager

This can't be correct that the compiler does not generate implicit
operator== methods himself, right?

Rgds,

Andreas

Re: [Quantlib-dev] Compilation problems with SUN CC

[Luigi B. <lui...@gm...>]

On Wed, 2009-02-18 at 17:03 +0100, Andreas Spengler wrote:
> I am trying to compile Quantlib on SUN Solaris 10 using SUN CC (I tried
> v5.7, v5.8 and v5.10, btw...)
> 
> Appearantly the SUN compiler is somehow missing operator== implementations
> for e.g. ExchangeRateManager, because I get the following error:
> 
> "/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list.cc", line 173: Error,
> badbinaryop: The operation "QuantLib::ExchangeRateManager::Entry == const
> QuantLib::ExchangeRateManager::Entry" is illegal.
> "/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
> Where, temwhileinst: While instantiating
> "std::list<QuantLib::ExchangeRateManager::Entry>::remove(const
> QuantLib::ExchangeRateManager::Entry&)".

Andreas,
	the compiler does not generate operator==, but that's the expected
behavior.  The problem is that your compiler is trying to instantiate
list::remove, which requires an operator==.  But that's wrong, since
list::remove is not being used and hence should not be instantiated.

> Perhaps I am using a bad compiler switch.

Maybe. Looking at your command line:

> libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
> -I/home/spenglan/local/include/boost-1_38
> -erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
> -KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
> -library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
> -Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
> exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o

a likely candidate would be -template=wholeclass. I don't have a Solaris
box available to check it, but if it tells the compiler to instantiate
all methods in a template class instead of just the ones that are used,
then it would cause the error above.  May you have a look at your
compiler documentation and check whether the above works as I guessed
(and if so, how can you specify the correct behavior instead?)

Luigi


-- 

I've finally learned what `upward compatible' means. It means we 
get to keep all our old mistakes. 
-- Dennie van Tassel 

Re: [Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Hi Luigi,

Luigi Ballabio schrieb:

> Looking at your command line:
> 
>> libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
>> -I/home/spenglan/local/include/boost-1_38
>> -erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
>> -KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
>> -library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
>> -Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
>> exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o
> 
> a likely candidate would be -template=wholeclass. I don't have a Solaris
> box available to check it, but if it tells the compiler to instantiate
> all methods in a template class instead of just the ones that are used,
> then it would cause the error above.  May you have a look at your
> compiler documentation and check whether the above works as I guessed
> (and if so, how can you specify the correct behavior instead?)

I should have guessed it. Unfortunately I somehow thought, that
memberwise comparison is added implicitly (like the copy constructor and
assignment operator are)...

I looked up this in the Sun compiler C++ user reference - and will try
it out tomorrow:

"When the compiler implicitly instantiates a template class, it
instantiates the static data members, the constructor, and the
destructor. However, the compiler does not implicitly instantiate any
other member function unless the function is explicitly referenced. To
force the compiler to instantiate all member functions when implicitly
instantiating a class, use the -template=wholeclass compiler option. To
turn this option off, specify -template=no%wholeclass, which is the
default."


Rgds,

Andreas