* We use our own copy of a *subset* of SLATEC to build the PDL bindings. Issues with the full SLATEC release should be minimal.
* f2c works fine for computational routines. The hard work is in the IO stuff which I don't believe we are using and if you are trying to interoperate with fortran. * Fixing the f77/fortran compiler issues for PDL builds for such a basic functionality as matrix inversion would be a big win. * The conversion should be straightforward and would be a nice fix until something better comes along.... Regards, Chris David Mertens writes: > > I've sometimes wondered about how we can get > slatec support when using gcc-4.x.x (no g77) > as the compiler. Is there some general advice > (ie not specific to any particular OS) on how > this can be achieved? > > > I believe that Chris has suggested running > f2c on the Slatec code and then including > that in our source code. I don't know how > well the f2c code works, though I think this > could potentially solve the problem. If it > did 90% of the work for us, we could probably > get the last 10% done by hand. Normally I > wouldn't suggest tweaking auto-generated code > by hand, but the Slatec code base hasn't > changed since the early 90s, so I think we > could safely do this once and never have to > touch it again. > > I'm not sure if we want to do this, however. > It's not clear to me if the Slatec code is > thread-safe: if it uses global variables or > even function-static variables, this would > impose a major hurdle to creating a true > multi-threaded PDL. I believe GSL provides > all all of the capabilities of Slatec and > much more, and is thread safe, but this would > require that we rewrite some of the basic PDL > modules (linear fitting is one I'm aware of) > to use GSL code instead of Slatec code. > > But, as a first-solution to the problem, > running f2c on the Slatc code might work. > > David
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
