Path: utzoo!attcan!uunet!mcvax!nikhefh!e07
From: e07@nikhefh.hep.nl (Eric Wassenaar)
Newsgroups: comp.sys.apollo
Subject: Re: SR10 librarian (lbr) functionality loss
Message-ID: <563@nikhefh.hep.nl>
Date: 8 Nov 88 14:06:02 GMT
References: <558@nikhefh.hep.nl> <3f6dd85c.ba7d@apollo.COM>
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 64



In <558@nikhefh.hep.nl> e07@nikhefh.hep.nl (Eric Wassenaar) wrote:
>>The SR10 librarian (lbr) has lost almost all functionality provided by
>>the SR9 and previous versions. It is a completely different utility now.
>>This is particularly cumbersome in fortran-oriented environments, with
>>certain methods for source code and library management.
>>Several years ago, the high-energy physics community, as one of the
>>big fortran user groups, has urged Apollo to provide a sophisticated
>>librarian with the same functionality as found in other heavy fortran
>>oriented environments. The fact that such utility was quickly provided,
>>was one of the reasons to remain in favor of Apollo workstations.
>>It is disappointing to notice that compatibility with previous releases
>>is now broken. Does Apollo have any short term plans to enhance the
>>librarian to provide the same functionality as it had before?

In <3f6dd85c.ba7d@apollo.COM> geiser@apollo.COM (Wayne Geiser) replied:
>Prior to SR10, the object module format was "allowed" to contain concatenated
>binaries. When this was fed to the librarian, it was able to take
>each of these object modules and make a separate entry in the library for each.
>At SR10 (and later, of course), the compilers produce COFF standard binary
>files.  This AT&T standard will not "allow" multiple object modules per binary
>file.  For this, and several less important reasons, we were forced to have the
>FORTRAN compiler place only one object module in each binary file.  The
>librarian sees only one object module and enters only it in the library.
>Unfortunately, we see no way to keep the past functionality and still continue
>with our policy of standards conformance.
>We do, however, have a workaround.  A shell script can be easily written
>to temporarily split the file into subprograms, compile them, and place
>the resulting binaries in a library.

I understand the reasons behind the change, but I want to mention again some
disadvantages of this approach in a heavy fortran development environment.

There is a big overhead in splitting a large source file into numerous
separate files, and invoking the compiler for each individual file.

One is forced to keep all individual files for debugging purposes, since
line numbers are relative to the input file to the compiler. This is an
adminstrative burden.

The old lbr could also give extensive information about the contents of a
library and its modules, like defined entry points, externals, common blocks
used, and numerous statistical data. This feature has disappeared.

The old situation provided facilities closely resembling those found in
traditional fortran environments (like Cray, CDC or IBM mainframes, or VAX/VMS).
The new situation is a step backward, albeit is the name of standards.
Perhaps certain applications need other standards...

Physicists don't choose Apollo because of its standards. Physicists choose
Apollo because of its superior characteristics to solve their particular
problems. E.g. if they want high quality graphics, they use GMR, not GKS.
They would even use GSR, if appropriate. I cannot imagine Apollo abandoning
such products in the future, although that would be a bigger and more
practical step towards standards and portability than adapting COFF format
for executables.

Eric Wassenaar
-- 
Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 5920412   Home phone: +31 20 909449    Telex: 10262 (hef nl)
Internet: e07@nikhefh.hep.nl  Bitnet: nikhefh!e07@mcvax.bitnet