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

[Barry Smith]

  In an ideal world compilers would have a standard, extensible API. 

  For years I’ve dreamed of day when Unix would be replaced with a modern operating system where there would be a one-to-one mapping between the C-lib interface to everything, the command line interface to everything and the python API to everything. And two of the three would be (largely) auto generated from the other.

   Barry

On Apr 16, 2014, at 6:57 PM, Jed Brown <jed at jedbrown.org> 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 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.)