vern%lbl-helios@LBL-RTSG.ARPA (Vern Paxson) (10/06/87)
I spent an inordinate amount of time today trying to read on a Sun the contents of an "ar" archive written on an HP9000. The problem was that ar on the HP generates non-standard archive headers. Instead of a line like: nlatt.f 560040370 204 20 100666 83836 ` it generates nlatt.f/ 560040370 204 20 100666 83836 ` This extra '/' is the one character they could have chosen which your typical ar can't chew on. I finally managed to get the archive read on a Eunice machine, renaming the screwy hash files it generated to what they ought to have been, rebuilding the archive, and moving the result to the Sun. Questions: 1. Is there an easier way to read the archive? (Hand-editing resulted in "malformed archive" errors.) 2. Is there a rational explanation for the incompatibility? I anticipate having to do more such transfers in the near future, so I'd appreciate any sage advice someone might be able to offer. Thanks. Vern Vern Paxson vern@lbl-csam.arpa Real Time Systems ucbvax!lbl-csam.arpa!vern Lawrence Berkeley Laboratory (415) G5 Oc-1
guy%gorodish@Sun.COM (Guy Harris) (10/06/87)
> I spent an inordinate amount of time today trying to read on a Sun the > contents of an "ar" archive written on an HP9000. The problem was that > ar on the HP generates non-standard archive headers. Actually, they *are* standard System V Release 2 or later archive headers. > This extra '/' is the one character they could have chosen which your > typical ar can't chew on. I presume "/" was chosen because it is the one character that is not valid in a file name (it's valid in a *path*name, but not in a file name; it separates the file names in a pathname). > 1. Is there an easier way to read the archive? (Hand-editing > resulted in "malformed archive" errors.) Not that I know of, short of porting an S5R2 or later "ar". > 2. Is there a rational explanation for the incompatibility? I presume the intent was to permit file names with trailing blanks in archives. Whether this was worth the incompatibility in an otherwise completely 4BSD-compatible archive format is left as an exercise for the readers. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/08/87)
In article <8710052355.AA03056@lbl-helios> vern%lbl-helios.arpa@lbl-rtsg.arpa writes: >ar on the HP generates non-standard archive headers. Instead of a line like: > nlatt.f 560040370 204 20 100666 83836 ` >it generates > > nlatt.f/ 560040370 204 20 100666 83836 ` The H-P "ar" appears to be working right. This is correct format for the System V version of "ar". The problem with the Berkeley version is that it couldn't handle embedded spaces in member names. It is possible (and easy) to make a single "ar" accept both forms of input archive; fix the one on your Sun to do that. The other difference between the two flavors of "ar" is that the System V object module table of contents has a different name and format and is automatically brought up to date by "ar" when an object member is updated (no more "ranlib", hooray!).
allbery@ncoast.UUCP (Brandon Allbery) (10/10/87)
As quoted from <8710052355.AA03056@lbl-helios> by vern%lbl-helios@LBL-RTSG.ARPA (Vern Paxson): +--------------- | I spent an inordinate amount of time today trying to read on a Sun the | contents of an "ar" archive written on an HP9000. The problem was that | ar on the HP generates non-standard archive headers. Instead of a line like: +--------------- Solution: change the '/' to a space. Don't merely delete it! As for it being "nonstandard": define "standard". There are four common archive formats: PDP-11 (binary header), System V Release 0 (text header, magic number "<ar>"), System V Release 2 and BSD (text header, magic number "!<arch>\n", only difference is that SVR2 version will correctly handle file names containing spaces because it delimits the file name with a slash). Not that file names containing trailing blanks are common... The HP uses System V Release 2 archives; the Sun, being a BSD machine, uses BSD archives. Converting between them is actually quite simple, given the single difference between them. (Be nice if one or the other would change so that they were compatible, though.) -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "...he calls _that_ a `little adventure'?!" - Cmdr. Ryker