summaryrefslogtreecommitdiff
path: root/gnu/egcs/libf2c/libU77/README
diff options
context:
space:
mode:
Diffstat (limited to 'gnu/egcs/libf2c/libU77/README')
-rw-r--r--gnu/egcs/libf2c/libU77/README40
1 files changed, 40 insertions, 0 deletions
diff --git a/gnu/egcs/libf2c/libU77/README b/gnu/egcs/libf2c/libU77/README
new file mode 100644
index 00000000000..bfedb90bd97
--- /dev/null
+++ b/gnu/egcs/libf2c/libU77/README
@@ -0,0 +1,40 @@
+19970811 -*-text-*-
+
+g77 libU77
+----------
+
+This directory contains an implementation of most of the `traditional'
+Unix libU77 routines, mostly an interface to libc and libm routines
+and some extra ones for time and date etc. It's intended for use with
+g77, to whose configuration procedure it's currently tied, but should
+be compatible with f2c otherwise, if using the same f2c.h.
+
+The contents of libU77 and its interfaces aren't consistent across
+implementations. This one is mostly taken from documentation for (an
+old version of) the Convex implementation and the v2 SunPro one.
+As of g77 version 0.5.20, most of these routines have been made
+into g77 intrinsics. Some routines have a version with a name prefixed
+by `vxt', corresponding to the VMS Fortran versions, and these should
+be integrated with g77's intrinsics visibility control.
+
+A few routines are currently missing; in the case of `fork', for
+instance, because they're probably not useful, and in the case of
+`qsort' and those for stream-based i/o handling, because they need
+more effort/research. The configuration should weed out those few
+which correspond to facilities which may not be present on some Unix
+systems, such as symbolic links. It's unclear whether the interfaces
+to the native library random number routines should be retained, since
+their implementation is likely to be something one should avoid
+assiduously.
+
+This library has been tested it under SunOS4.1.3 and Irix5.2 and there
+has been some feedback from Linux; presumably potential problems lie
+mainly with systems with impoverished native C library support which
+haven't been properly taken care of with autoconf.
+
+There's another GPL'd implementation of this stuff which I only found
+out about recently (despite having looked) and I haven't yet checked
+how they should be amalgamated.
+
+Dave Love <d.love@dl.ac.uk> Aug '95
+(minor changes by Craig Burley <burley@gnu.org> Aug '97)