Re: New gnucap development snapshot

al davis wrote:
> On Wednesday 06 December 2006 23:03, Dan McMahill wrote:
> 
>>Builds ok and seems to run some of the examples ok on both
>>solaris-2.9/sparc and NetBSD-2.0/alpha both using gcc3.  You
>>already know of the issues with the sun studio compilers.
> 
> 
> The one about something in the STL headers being multiply 
> defined, right?

this one:

/opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I. -I..   -D__func__='""' 
-DNDEBUG  -g -c -o d_bjt.o d_bjt.cc
"/opt/SUNWspro/prod/include/CC/Cstd/./map", line 251: Error: Multiple 
declaration for std::map<const std::string, PARAMETER<double>, 
std::less<const std::string>, std::allocator<std::pair<const 
std::string, PARAMETER<double>>>>::insert(const std::pair<const 
std::string, PARAMETER<double>>&).
"u_parameter.h", line 170:     Where: While specializing "std::map<const 
std::string, PARAMETER<double>, std::less<const std::string>, 
std::allocator<std::pair<const std::string, PARAMETER<double>>>>".
"u_parameter.h", line 170:     Where: Specialized in non-template code.
"d_bjt.cc", line 555: Warning: c2 hides MODEL_BJT::c2.
"d_bjt.cc", line 589: Warning: c4 hides MODEL_BJT::c4.
"d_bjt.cc", line 890: Warning: m hides COMMON_BJT::m.
1 Error(s) and 3 Warning(s) detected.
gmake[2]: *** [d_bjt.o] Error 1

Also, I need to figure out what the right thing is for -rdynamic with 
that compiler.  But since we don't get that far it doesn't matter yet.

What we did for pcb was something like:

# FIXME:  for now, only try to add -rdynamic if we're using gcc.  We really
# need to figure out what the correct test is here.  In the mean time, this
# should let things build with SunPRO again.
if test "x$GXX" = "xyes"; then
AC_MSG_CHECKING([If the compiler accepts -rdynamic])
old_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS -rdynamic"
AC_LINK_IFELSE([int main(){}],
         [AC_MSG_RESULT([yes])],
         [LDFLAGS="$old_LDFLAGS"
         AC_MSG_RESULT([no])
         ])
fi

The problem was when I tried just linking with -rdynamic, I still got a 
return value of 0 even though the wrong thing happened.  This is 
something I need to revisit since there needs to be a more robust test.

-Dan