Re: f/runtime/Makefile.in: mclock_.o left out of libU77

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Craig Burley]

>Craig -- if there's a reason we should not include this change, let
>me know and I'll remove it.

Not that I know of -- thanks to Mumit, I've added the patch to the
forthcoming 0.5.21!

This might be the result of a difference in approach to handling
libraries taken by Dave Love, author of g77's libU77 *and* most
of the original library configuration stuff (e.g. he did lots of the
original work getting libf2c into g77 so people wouldn't have
to grab and build it separately, back a couple of years ago), and
myself.

Dave knows lots more about configuration tools and such, and has
generally taken the approach of having the run-time configuration
determine what the system can handle, build the library accordingly,
and *also* build the compiler accordingly.

The result of his approach would be that, for example, g77's libf2c
configuration might notice that the system being targeted for
code generation (the Z system in the X->Y->Z model, as I call it,
meaning use system X to build compiler that runs on Y generating
code to run on Z) doesn't support `symlink()', i.e. symbolic links.

To handle this, his approach would avoid compiling any libU77 function
that provided access to symlink() to Fortran code *and* disable
the g77 SYMLNK() intrinsic accordingly.

The first thing I noticed about this was a conceptual circular
dependency, though one that could be worked around in practice
(if I understood more about configuration issues).  The run-time
library, in theory at least, could be written (partially) in Fortran
and thus need g77 to be built first; but that would require the
library to depend on g77 being built (which in fact seems to be
the case, for a few obscure reasons I can't remember), which is a
problem if g77 depends on the *library* being built (really,
configured) first.

But the other problem I have with this is that I think the *Fortran*
dialect presented to a user should be *independent* (ideally) of
the vagaries of the underlying system.

That is, I don't see why the *user* should be forced to *also*
detect that symlink() isn't supported, therefore conditionally
compile (using a preprocessor, which g77 supports, grudgingly ;-)
code using the SYMLNK() intrinsic.

Instead, I figure this should be handled by having SYMLNK() return
an error code saying "this isn't implemented here".

But this is all theoretical on my part, and definitely g77 is
currently a reflection of my not being much of an expert on the
ways people actually will write code, being much more concerned
with perhaps how they *should* (be able to) write code in a GNU
coding environment (meaning, care less about the underlying hardware
than is typical in the proprietary world), and not really having
the time to tackle these issues yet.

So, mclock_() being left out might have been a mistake, but in
the past, Dave purposely left some of his libU77 routines out
of the g77 builds to avoid problems on, e.g., DOS machines, and
I've tended to put them back in, with the hopes of finding the
most elegant, consistent ways around the problems we expect to
encounter.

Note that 0.5.21, not yet out, is pretty much reflected in egcs from
what I gather (not having looked myself, sigh), and you'll notice
I recently added some more code to libU77 routines (perhaps symlnk_()
is an example; I'm pretty sure mclock_() is), along with their
documentation, that causes them to return a clean, defined indicator
in cases where their underlying routine (e.g. symlink() or clock())
is unavailable.

However, avoiding collisions on "clean, defined indicators" can be
non-trivial.  As a made-up example, suppose an intrinsic people
use in Fortran named FOOFEATURE() that returns the status code for
`foofeature()' in the underlying system.  If there's no provision
made for `foofeature()' to return "I'm not implemented here", g77's
libU77 has to add one, but this has to be *distinct* from any code
any other system might return.  This doesn't have to be numerically
distinct globally across system, but, if not, it *does* have to be
symbolically distinct on each system, and each system must provide
a way for Fortran code to specify those symbols.

For now, it seems adequate that MCLOCK() returns -1 if the system
doesn't have `clock()' or whatever, and that other routines
return `ENOSYS' since that seems to be a canonical way to indicate
an unimplemented function.

In general it has been my observation that we've dug ourselves a
big "hole" that we've ever been trying to fill, haphazadly, by
designing gcc and related products (including the whole autoconf
universe, though at least autoconf regularizes much of the mess)
to dynamically adapt to their environment, which can make doing
stuff like cross-compiles, or even highly efficient, reliable builds,
quite difficult.  The advantages of our current approach are
obvious, and hard to give up, but in general I'd like to, whenever
possible, separate out "discovery" about a system's nature from
"adaptation" to it and that, in turn, from "coding" for the product.

(E.g. I'd prefer gcc get out of the fixincludes business, and
leave that sort of thing to a separate product, a `gnuize' product,
that does all the GNU fixing up, autodetection, and configuring,
producing a data base that all other GNU products use, by default
unless overridden, to accomplish all the things their code *assumes*
will be needed.)

Just thought I'd put these rambling thoughts of mine on record here,
FWIW.  I still have a lot to learn about what it'll take to make
such an approach practical in the long run, but it does seem like
a reasonable direction to lean in when thinking of how to handle
specific situations like SYMLNK() or MCLOCK() in g77.  So I'm certainly
not asking anyone to do any work, or change their approach, based
on what I'm saying here.  (I'm a big fan of the minimalist approach
to product design.  A compiler should generate code for a machine;
its job does *not* include dynamically discovering what that machine
is, the details of what it supports, etc., as that is the job of
another tool.  gcc is to compilers what Emacs is to text editors.
I'm highly grateful for both, but always thinking of ways to reduce
their complexity while making the end result more adaptable, faster,
smaller, and so on.  It's probably a whole 'nother project than GNU,
however, maybe a GTNG -- `GNU, The Next Generation'.  ;-)

        tq vm, (burley)

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Jeffrey A Law]

  In message <199708220931.FAA29542@churchy.gnu.ai.mit.edu>you write:
  > >Looking at the ChangeLog file, I see:
  > >
  > >Apr 8 1997  Daniel Pettet  <dan.pettet@bchydro.bc.ca>
  > >
  > >	* Makefile.in: Add libU77/mclock_.o and libU77/symlnk_.o to UOBJ.
  > >	...
  > >
  > >So it looks like the fact it is missing is an accident.  This also points
  > >out that symlnk_.o is missing too, and probably should be added in.
I've added symlnk_.o.  It will appear in the next snapshot.

jeff

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Craig Burley]

>Looking at the ChangeLog file, I see:
>
>Apr 8 1997  Daniel Pettet  <dan.pettet@bchydro.bc.ca>
>
>	* Makefile.in: Add libU77/mclock_.o and libU77/symlnk_.o to UOBJ.
>	...
>
>So it looks like the fact it is missing is an accident.  This also points
>out that symlnk_.o is missing too, and probably should be added in.

Oops.  Smoking gun compared to my vague sense of wonder over this
a couple of days ago.

Looks like when I pulled in Dan Pettet's excellent work on the libU77
"externals" interface, I got the ChangeLog entries for Makefile.in,
but not the changes themselves.

Thanks for pointing this out!  I'm starting to fix this in g77 0.5.21
now, and will upload the appropriate patches to ~fortran/dev/ when
I'm done, which Jeff (still dutifully, at least for now ;-) checks
out on occasion for stuff to snarf into egcs' version of g77.  I'll
poke around for other stupid mistakes I made, as well, in this area.

        tq vm, (burley)

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Jim Wilson]

	Was there a reason to leave mclock out of libU77? If not, here's a patch
	to f/runtime/Makefile.in:

Looking at the ChangeLog file, I see:

Apr 8 1997  Daniel Pettet  <dan.pettet@bchydro.bc.ca>

	* Makefile.in: Add libU77/mclock_.o and libU77/symlnk_.o to UOBJ.
	...

So it looks like the fact it is missing is an accident.  This also points
out that symlnk_.o is missing too, and probably should be added in.

Jim

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Jeffrey A Law]

  In message <199708210305.WAA28627@mercury.xraylith.wisc.edu>you write:
  > Was there a reason to leave mclock out of libU77? If not, here's a patch
  > to f/runtime/Makefile.in:
None I can think of -- I've installed the change.

Craig -- if there's a reason we should not include this change, let
me know and I'll remove it.

Jeff

f/runtime/Makefile.in: mclock_.o left out of libU77

[Mumit Khan]

Was there a reason to leave mclock out of libU77? If not, here's a patch
to f/runtime/Makefile.in:

*** f/runtime/Makefile.in.orig	Wed Aug 20 22:02:14 1997
--- f/runtime/Makefile.in	Wed Aug 20 22:02:33 1997
*************** UOBJ =  libU77/VersionU.o libU77/gerror_
*** 133,137 ****
  	libU77/lnblnk_.o libU77/hostnm_.o libU77/rename_.o libU77/fgetc_.o \
  	libU77/fputc_.o libU77/umask_.o libU77/system_clock_.o libU77/date_.o \
! 	libU77/second_.o libU77/flush1_.o libU77/alarm_.o
  
  F2CEXT = abort derf derfc ef1asc ef1cmc erf erfc exit getarg getenv iargc \
--- 133,138 ----
  	libU77/lnblnk_.o libU77/hostnm_.o libU77/rename_.o libU77/fgetc_.o \
  	libU77/fputc_.o libU77/umask_.o libU77/system_clock_.o libU77/date_.o \
! 	libU77/second_.o libU77/flush1_.o libU77/alarm_.o \
! 	libU77/mclock_.o
  
  F2CEXT = abort derf derfc ef1asc ef1cmc erf erfc exit getarg getenv iargc \

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/