[cgma-dev] Finding ACIS in Cubit

[Tim Tautges]

Yeah, we've seen this before, with many of the same symptoms.  The root cause of this all is, as you point out, the fact 
that 2 versions of libstdc++ are being linked.  I offer the following anecdotes, and some general points afterwards:

- for various obscure reasons, you should only use cubit version 10.2 if you're going to have MOAB and CGM interacting 
together.  We have an updated tarball for CGM from cubit 11.x, but haven't had time to incorporate those changes into 
Argonne's version of it.

- Applications using MOAB and CGM have worked in the following configurations:
. 32 bit, gcc4.2, gcc4.3, CGM on cubit
. 64 bit, gcc4.3 compiled locally and installed under /usr/local/gcc-4.3, CGM on cubit
. 64 bit, gcc4.3, CGM on ACIS

- I've played around with hand-constructed link statements to try and change the order of vers 5 and 6 of libstdc++. 
Although I've been successful at changing that order (as listed by ldd), the code still dies the same way

- libcubiti19.so in Cubit 12.0 still depends on both versions of libstdc++.so.

Discussion:
In the not-too-distant future we'll need to do something about this, for several reasons.  First, more and more 
platforms where CGMcubit+MOAB apps need to run will be 64-bit with gcc4.3 installed by default (where this breaks). 
Second, information in ACIS' documentation leads me to believe Cubit will be working off of runtime license keys in the 
not too distant future as well (Cubiteers subscribed to this list, you're welcome to chime in here...).  Several options 
are under consideration, but nothing is far enough along to share at this point.

- tim

Jed Brown wrote:
> I don't know where to ask about this but maybe you can help.
> 
> When I link with libcubiti19.so, I get the warning
> 
> /usr/bin/ld: warning: libstdc++.so.5, needed by /home/jed/usr/cubit-10.2/bin/libcubiti19.so, may conflict with libstdc++.so.6
> 
> I was getting strange behavior from iRel resulting in seg-faults
> sometimes during program execution and sometimes from invalid frees in
> static destructors (called after main).  Even a completely empty main
> segfaults when linked to both iMesh and iGeom (hence cubit), but it does
> it after main.  I've run this under a debugger and valgrind.  As the
> attached test case shows, I always have problems when linked against
> cubit.  In nontrivial programs, I think I'm seeing incorrect behavior
> prior to seg-faults.
> 
> Look at the first error in the log 'kunyang-both'.  Memory allocated by
> STL within iMesh_load() is incorrectly going through a template instance
> in libcubiti19.so and then being freed by a current instance.  At first
> glance, it seems possible to LD_PRELOAD all template instances required
> by MOAB, but this would make symbols inside Cubit resolve incorrectly
> with respect to the inlined instances (and I recall seeing the memory
> bug go the other way during earlier debugging).
> 
> I'm starting to doubt whether this can work properly with a system
> significantly different from the build system (presumably RHEL4).  While
> I could create such a system for testing, it's really not feasible on a
> cluster.  I think I asked about this before, but is there any way to
> export geometry in a different format?
> 
> 
> Jed

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706