Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!ulowell!apollo!geiser
From: geiser@apollo.COM (Wayne Geiser)
Newsgroups: comp.sys.apollo
Subject: Re: SR10 librarian (lbr) functionality loss
Message-ID: <3f6dd85c.ba7d@apollo.COM>
Date: 2 Nov 88 18:02:00 GMT
References: <558@nikhefh.hep.nl>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 65

>The SR10 librarian (lbr) has lost almost all functionality provided by
>the SR9 and previous versions. It is a completely different utility now.
>Its new primitive behaviour is just like that of the unix 'ar' utility.

The librarian has not changed.  The object format the compilers produce has
changed.

Prior to SR10, the object module format was "allowed" to contain concatenated
binaries (e.g. a module that had several FORTRAN subprograms would create one
binary file with several completely separate object modules).  This is the
reason that one had to bind all FORTRAN programs that had more than just a
PROGRAM subprogram.  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.

>This is particularly cumbersome in fortran-oriented environments, with
>certain methods for source code and library management.
>Suppose one has a big source file foo.ftn containing many fortran source
>modules. Compilation results in one object file foo.bin containing all
>object modules.
>The old lbr would be able to put those object modules as individual
>entries into a library, which could be loaded as needed.
>The new lbr just puts the whole foo.bin as one entry into the library.
>If one loads from this library, and needs only a few modules, one gets
>everything.
>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.
>
>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?

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 (if
you'd rather not write it yourself, let me know and I'll dig up the one I
wrote) to temporarily split the file into subprograms, compile them, and place
the resulting binaries in a library.  In this way, you may still continue to
maintain your sources in one (or several) huge files and yet get each
subprogram listed separately in the library.

>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


-- 
Wayne Geiser
Apollo Computer, Inc.
{mit-erl, yale, uw-beaver, decvax}!apollo!geiser