Satish Balay <[email protected]> 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.
pgp8idOUq9uaH.pgp
Description: PGP signature
