Hi Duncan,
I'm not a maintainer, but I think putting GSL_CBLAS_LIB in private will
break many things. The user needs to link against cblas library and by
design GSL is not linking in any cblas lib when libgsl is built. The
idea is to give the use the freedom to choose and this freedom comes
with the cost that one cannot rely on implicit linking.
The other changes make sense to me, but not up to me to decide (obviously).
Cheers,
Peter
On 3/26/2019 9:13 PM, Duncan Macleod wrote:
Dear GSL developers,
I think there is an issue with the way Libs is declared in the GSL
pkgconfig file (gsl.pc) that results in downstream packages overlinking
against GSL's upstream dependencies.
I believe the following patch will correct this by using Libs.private to
indicate GSL's upstream dependencies in a way that downstream packages
aren't 'forced' to link against them also when using pkgconfig:
----------
diff --git a/gsl.pc.in b/gsl.pc.in
index 5e9ef218..f5705636 100644
--- a/gsl.pc.in
+++ b/gsl.pc.in
@@ -7,5 +7,6 @@ GSL_CBLAS_LIB=-lgslcblas
Name: GSL
Description: GNU Scientific Library
Version: @VERSION@
-Libs: @GSL_LIBS@ ${GSL_CBLAS_LIB} @GSL_LIBM@ @LIBS@
+Libs: @GSL_LIBS@ ${GSL_CBLAS_LIB}
+Libs.private: @GSL_LIBS@ ${GSL_CBLAS_LIB} @GSL_LIBM@ @LIBS@
Cflags: @GSL_CFLAGS@
----------
(this requires pkg-config >=0.18.0)
I'm not sure whether GSL_CBLAS_LIB is an upstream dependency, or something
that is actually provided by GSL, if the former then it should also be
moved into Libs.private.
If any of this is in error, or I have misunderstood how GSL actually works,
please accept my apologies.
Thanks
Duncan
