Re: No libgsl.a in version 0.5 under OSF1

[Dave Morrison <dave at bnl dot gov>]

Hi Mark,

OK, I'm game.  First, there are a few things that need a bit of
attention and advice - if you blindly follow my prescription for
assembling libgsl.so it'll fail, in part because of some multiply
defined symbols.  Here are the ones I see: 

`solve_tridiag' is defined in linalg/tridiag.c and
interpolation/tridiag.c

`brent_init' is defined in roots/brent.c and min/brent.c

`brent_iterate' is defined in roots/brent.c and min/brent.c

`newton_iterate' is defined in roots/newton.c and multiroots/newton.c

The functions defined in these different places are pretty darn near
identical ... but not quite.  Any idea how best to handle this?  Can one
or the other instance be defined as static and only used within its own
subpackage?

And it looks like we'd need to make a configure option to choose between
adding either the symbols in libgslblascblas.so or those in
libgslblasnative.so to libgsl.so.

Mark Galassi wrote:

> If someone wants to pass on a patch against CVS to make it work, that
> would be wonderful!

Cheers,
Dave

-- 
David Morrison  Brookhaven National Laboratory  phone: 631-344-5840
                Physics Department, Bldg 510 C    fax: 631-344-3253
		          Upton, NY 11973-5000  email: dave@bnl.gov