Hi Peter,
On Fri, 1 Dec 2006, Peter W. Draper wrote:
> Actually it probably does. I didn't intend the test program to run
> successfully (just test what symbols or libraries turn up missing, as it
> did), so it's dying just where it should, that's when it accesses the NDF
> name. Maybe this library will now load into a JVM?
It wouldn't, but...
> I guess if it's still broken it there could be some incompatibilities with
> this libgcc_s and the system one (should be in /usr/lib), in which case
> you'll need to persuade g95 to use the system versions. We'd had some success
> with just replacing such libraries in g95 with links to the system ones
> (needed for FC/6, which uses gcc4.1).
...softlinking the g95 libgcc_s to the system version fixed the problem. I
don't know what other consequences this will have on the rest of the
software suite, but at least SPLAT can load up NDFs natively now. :-)
I'll check in the libsplat.dylib as part of the jar file.
Cheers,
Brad.
|