[petsc-dev] [petsc-maint] problem installing petsc 3.4

[Satish Balay]

On Wed, 16 Apr 2014, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> > Whenever we make such assumptions - there is always a corner case
> > where something else fails.
> >
> > [the current issue is an example of one such assumption.]
> 
> Yes, but the current failure case is complicated because people see a
> library they've never heard of and probably is not documented anywhere.
> "How did PETSc come up with this insane thing?"  I wouldn't take CMake
> as a model actor (it's inherent assumptions seem to break more than we
> do), but they use the Fortran compiler to link and don't try to include
> private libraries on the link line.

Perhaps things have improved now. There used to be a bunch of c++
compilers which requilred cxx as the linker for a c++ main.

> Perhaps it would make sense to make the autodetect code try this first?
> 
> 
> (Wrappers always cause this sort of problem.  In an ideal world, the
> compiler for each language should have a standard interface to query a
> list of required libraries, then we would always link by calling ld
> directly.)

Agree. And the current detection code doesn't handle all compiler
idiosyncrasies.  [intel compiler loves to use "-bstatic -lfoo
-bdynamic -lbar" - which configure can't handle]

However in the current situation - the alternative of using
with-clib-autodetect=0 LIBS='' etc is a reasonable fallback.

Satish