Please consider adding extern "C" block to headers for C++ users

Thanks for investing the time to develop ATLAS. I work on a product that generates C and C++ code from a higher level language that includes matrix operations. To help optimize our generated code, we're looking into generating calls to BLAS libraries (via the CBLAS interface).

When testing with various libraries and language configurations, we came across the fact that the ATLAS cblas.h header doesn't declare functions as extern "C" for C++ compilation. This will cause a difficult to diagnose linker failure for our C++ users who decide to try ATLAS when this feature ships. C++ is becoming more of a focus for our customers, and I'd love to be able to make integration of various BLAS libraries, including ATLAS, as simple as possible for those customers. We can certainly document the workaround you've shown in the errata to minimize user pain.

I came across:

http://math-atlas.sourceforge.net/errata.html#CPPheaders

and thought I'd put in a vote for adding and extern "C" block protected by #ifdef __cplusplus checks to the headers.

The last request for this I could find was updated in 2009:

https://sourceforge.net/p/math-atlas/support-requests/550/

My arguments for the addition of extern "C" are:

• As that requestor noted, debugging the absence of extern "C" is tricky since it manifests as a link error because of name mangling differences between C and C++.
• Many other CBLAS headers provide this affordance including OpenBLAS, the Netlib reference BLAS (http://www.netlib.org/blas/cblas.h), and Intel MKL. Adding it would improve interchangeability and allow code like the code that we generate to remain mostly agnostic of which BLAS library is being used.
• I'm not aware of any functional downsides to existing C users if the extern "C" is protected by #ifdef guards. For existing C++ users who have already added their own extern "C" wrappers, it looks like extern specifiers nest and prefer the innermost specifier:
  http://en.cppreference.com/w/cpp/language/language_linkage
  so this change shouldn't break them either.

Thanks for the consideration.