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

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Wed, 16 Apr 2014, Jed Brown wrote:
>
>> 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.

When PETSc is built as a C library depending on some C++ package (e.g.,
Elemental), we should have a reliable way for users to link independent
of whether their main is C, C++, or Fortran.  My recollection is that in
the majority of cases, C++ ends up just needing -lstdc++ while Fortran
has all manner of idiosyncrasies.

>> (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.

It's an acceptable fallback, but it's "weird" (what other package needs
--with-clib-autodetect=0?) and poorly documented and would be nice to
not need a fallback.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140416/92f62787/attachment.sig>