No Subject

>  > Anyone have better ideas for extracting the relevant info?  (This was
>  > more foolproof when the f/ directory looked after the runtime.)
>What precisely are the issues.
>
>Other runtimes don't have to play these kinds of silly games to the best of
>my knowledge (ok, ignoring libobjc for the moment).  What problems is all
>this hair trying to resolve?

Given

struct {
  f2c_unit unit;
  f2c_len length;
  } f2c_struct;

where `f2c_unit' and `f2c_len' are f2c-defined types (not their real names),
one of the main issues is trying to ensure that the f771 compiler
module agrees with the libg2c run-time library regarding the resolved
forms of those types (their sizes, etc.).

That is, when g77 compiles code, f771 has to know what the underlying
types of the members of `f2c_struct' so it can build instances of that
structure, and libg2c has to know the same thing, so it can contain
C code that manipulates such instances.  (There are various objects
like `f2c_struct' in the libg2c interface, including arguments to
functions.)

The way this currently works is that f771 has various preprocessor
conditionalization that takes place in egcs/gcc/f/com.c, libg2c's
configure.in replicates the decision-making, and they both depend
on egcs/gcc/f/com.h and other #include files being the same, so they
come to agreement.

I don't know what other approaches are used.  My current feeling is that,
ideally, if we were architecting this from scratch (`libg77'), we'd
design libg77 to internally use the "maximum efficient size" for the
types -- e.g. 32 bits on x86, 64 bits on Alpha.  Then, we'd provide
one external interface per combination of potentially useful type
(e.g. 32-bit and 64-bit interfaces, maybe 16-bit as well), accordingly
named.  Each external interface would either copy or promote the values,
or truncate (and crash on overflow), as part of performing the internal
implementation.

But, libf2c is not libg77, and doesn't really have that degree of
flexibility.  It's designed to have most of these sorts of choices
made by adjusting build-time parameters (via preprocessor macros,
sometimes by hand-editing the source) and rebuilding the library, perhaps
the compiler (f2c, or g77) as well.

For libg2c, we nail down some of that, replace the hand-editing with
automation, etc.

The result is that libg2c doesn't end up too different from libf2c
(important, since the libF77 and libI77 components are best understood
and maintained by the f2c maintainer, who doesn't work directly on any
version of g77), but tries, anyway, to fit within the g77 framework.

That's my take on the overview of what's going on.  I'm not really
up on the specifics of the configury stuff, either libg2c's or
egcs's, though I learn more on occasion, when necessary, in fits
and starts.

(I assume you aren't wondering about other configury stuff, like
that which tries to accommodate different versions of UNIX, different
I/O models, etc., though that's important to get right as well.
Presumably most libraries already deal with this sort of thing,
but without having to pull in any source code from their compiler
siblings during configuration as does libg2c.)

        tq vm, (burley)