Path: utzoo!utgpu!attcan!uunet!husc6!bbn!ulowell!apollo!geiser From: geiser@apollo.COM (Wayne Geiser) Newsgroups: comp.sys.apollo Subject: Re: SR10 librarian (lbr) functionality loss Message-ID: <3f960034.ba7d@apollo.COM> Date: 10 Nov 88 17:39:00 GMT References: <558@nikhefh.hep.nl> <3f6dd85c.ba7d@apollo.COM> <563@nikhefh.hep.nl> Organization: Apollo Computer, Chelmsford, Mass. Lines: 86 >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. Agreed. >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. Not so. When this problem was discovered a solution was implemented. It involves placing %LINE [,] directives in each "split-out" file so as to point back to the original file. This can be done automatically by the same shell script that breaks the sources apart (it is in the one I wrote). Note: Don't look for %LINE before SR10.1. >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. I'm sorry, I don't know enough about lbr to address this point. >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 I'm sorry, I thought you wished to have a technical conversation on the problem you were having. I understand your complaints. However, we must follow the direction that Marketing tells us (through research) will generate the most customers (and, therefore, the most money). If you wish to argue that the direction Apollo has chosen is not the best, someone from the Marketing organization will have to take over. -- Wayne Geiser Apollo Computer, Inc. {mit-erl, yale, uw-beaver, decvax}!apollo!geiser