This email traffic reminds me of an undocumented compiler "quirk" I've found with many PETSc versions on many different machines...
 
Strictly speaking, PETSc and libMesh should be built with the same compilers.  However, I have never had an issue building PETSc with gcc and then building libMesh with intel icc.  Conversely, I've had plenty of trouble building PETSc with icc and then libMesh with gcc.  It seems to manifest as bizarre, random crashes that make no sense whatsoever.  Note that this is all building PETSc with the C interface, so there are no ABI issues to contend with.
 
If you want to be able to build libmesh with a number of compilers I would either (i) build PETSc with all of them as well or (ii) just build PETSc with gcc.
 
-Ben
   
 
 
-----Original Message-----
From: Michael Povolotskyi [mailto:povolotskyi@ing.uniroma2.it]
Sent: Friday, June 24, 2005 6:02 AM
To: KIRK, BENJAMIN (JSC-EG) (NASA)
Cc: Libmesh-users@lists.sourceforge.net
Subject: Re: [Libmesh-users] crash in example 10

Dear all,
we menage to solve the problem by using GNU Fortran instead of Intel v. 8.0.
Thank you for help,
Michael.

KIRK, BENJAMIN (JSC-EG) (NASA) wrote:
I'm back at work and now have access to my petsc-2.3.0 build...
 
Here is how I configured petsc:
 
./config/configure.py  --with-cc=gcc --with-cxx=g++ --with-fc=g77 --with-blas-lapack-dir=/software/ia32/intel/mkl-7.0 --with-mpi-dir=/software/ia32/mpi/mpich-1.2.6-gcc --with-debugging=0 --with-shared=1 --useThreads=0
 
(Note that --useThreads=0 is automatically set on RH9 machines by the PETSc configuration script due to a known issue.  Perhaps you are suffering from this issue? Maybe you need --useThreads=0 on your platform as well?  BTW, what platform are you on?)
 
Beyond that, I have tested libMesh-0.5.0/PETSc-2.3.0 with gcc-4.0.0 and gcc-3.4.3 on a Fedora Core 3 machine, and ex10 runs with no issue. 
 
Is both PETSc and libMesh built with the same compiler?  Are there any special flags you are passing ./configure for libmesh? 
 
In any case,  I would suspect something is amiss with PETSc.  The library is primarily developed under gcc, and portability is maintained by testing with a number of compilers.  I seriously doubt this is a compiler issue, but rather too many libraries not *quite* working together.
 
Looking forward to solving this problem...
 
-Ben
 
 
-----Original Message-----
From: libmesh-users-admin@lists.sourceforge.net [mailto:libmesh-users-admin@lists.sourceforge.net] On Behalf Of Michael Povolotskyi
Sent: Friday, June 17, 2005 4:49 AM
To: John Peterson
Cc: Libmesh-users@lists.sourceforge.net
Subject: Re: [Libmesh-users] crash in example 10

Hi John,
so far we didn't make any progress.

I'd like to know how do you configure PETSc?
Which fortran compiler and libraries are used?

Michael.


John Peterson wrote:
Hi Michael,

 > Hi John,<br>
 > we found that there are two "ways" to make it work:<br>
 > 1) subsititute dynamic_cast by static_cast:<br>

I imagine this is only working by chance, since as far as I
know static_cast<> is equivalent to the old C-style cast, and
does not take into account class hierarchies like dynamic_cast.
I was also under the impression that dynamic_cast returned a NULL
pointer upon failure (thus the reason for checking rhs_elem
against NULL and returning false upon failure)  In case the
cast *is* failing and *is not* returning a NULL pointer, then that
could definitely cause the code to crash...

Does anything happen if you change the if-test to the following?

// If we cannot cast to an Elem*, rhs must be a Node
if (rhs_elem == static_cast<const Elem*>(NULL))
  return false;


 > 2) disable PETSc :)

Well that is just plain weird, I have never seen something like
that before!


 > Do you think that it may be related to the version of PETSc or to the
 > C++ compiler version?<br>

I doubt it's related to PETSc since we have successfully run the
examples in 2.3.0 before.  The only thing I haven't tried seems to be
GCC-3.4.3, which is apparently a bug-fix for 3.4.2...
If you are feeling adventurous, you might try building
libmesh (and petsc) with GCC-4.0.0 as well and seeing if the segfault
just goes away.


-John

P.S. One other thing I might be concerned with is what happens with
dynamic_cast in the presence of multiple inheritance.  An Elem is
multiply inherited from DofObject and ReferenceCountedObject, but I've
never heard bug reports about something like that.  In any case, what
happens if you make the destructor for ReferenceCountedObject virtual?
Probably nothing, but I did read somewhere that any class which is
inherited from should have a virtual dtor.



  


-- 
------------------------------------------------------------
Michael Povolotskyi, Ph.D.
University of Rome "Tor Vergata"
Department of Electronic Engineering
Viale Politecnico, 1 - 00133 Rome - Italy 

Phone + 39 06 72597367
Fax   + 39 06 2020519
http://www.optolab.uniroma2.it/pages/moshe/moshe.html
-------------------------------------------------------------
    
------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users


-- 
------------------------------------------------------------
Michael Povolotskyi, Ph.D.
University of Rome "Tor Vergata"
Department of Electronic Engineering
Viale Politecnico, 1 - 00133 Rome - Italy 

Phone + 39 06 72597367
Fax   + 39 06 2020519
http://www.optolab.uniroma2.it/pages/moshe/moshe.html
-------------------------------------------------------------