On 02/07/07, Neil Williams wrote:
Is this the same cblas as usr/lib/libgslcblas.so.0 in libgsl0 http://packages.debian.org/stable/math/libgsl0 ?
This is what I was referring to.
libgsl0 may be large but it doesn't bring in any extraneous dependencies.
I'll give it a shot.
It only seems to increase the risk of mysterious bugs if you are using two different fortran libraries that are built against *VERY* different compilers : gcc-3.4 and gcc-4.2. Having one package depend on both libgfortran2 and libg2c0 could be a source of weird bugs. As maintainer of libitpp, it will be your job to fix them! (in conjunction with libitpp upstream). GnuCash has had similar problems - even now it still depends on libglib1 because of a dependency on an old library that has not been updated. (The bug report is over a year old now.) These things tend to bite eventually because the old library has to be removed from Debian at some point.
Would you advise me to retain the lapack dependency and stay with refblas, or add the gsl dependency? Also, I am not clear how to avoid the lapack dependency, which forces me to depend on an old compiler.
lapack would appear to be less of a potential headache than atlas and the way that the libraries are arranged means that atlas is still a usable alternative when installing the binaries. It is just worth being aware that lapack may complicate things when trying to fix bugs in libitpp.
Well, since I have to depend lapack for features, I am unable to figure out a way to avoid the old gcc depends (through libg2c0).
I think you could at least try a pbuilder run with--with-cblas=gslcblas enabled in your ./configure arguments.
I'll do that. Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
