Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hc!ames!sri-spam!milk10!robert
From: robert@milk10..istc.sri.com (Robert Allen)
Newsgroups: comp.sys.hp
Subject: Re: Where are the netinet files?
Message-ID: <12221@sri-spam.istc.sri.com>
Date: 21 Apr 88 19:14:58 GMT
References: <12104@sri-spam.istc.sri.com> <5570033@hpfcdc.HP.COM>
Sender: nobody@sri-spam.istc.sri.com
Reply-To: robert@milk10.UUCP (Robert Allen)
Organization: SRI International
Lines: 44

In article <5570033@hpfcdc.HP.COM> rml@hpfcdc.HP.COM (Bob Lenk) writes:
+>                  The biggest problem I've encountered thus far is finding
+>    a lot of the .h system files on the HP that are on the Sun.
+
+SunOS is a BSD-based system.  HP-UX is a System V compatible system.
+The headers you mention are from BSD.  Although we do provide many
+BSD features (and headers) we don't provide them all.  As such, porting
+BSD code is not always painless (or even easy).

    No kidding.  I'm trying to port gated and having a tough time.  Code
    which compiled correctly on a Vax and Sun won't compile on the HP
    (9000/300).  In this case it may be that the code shouldn't have
    compiled on the Sun and Vax because of the way in which it was written,
    but who knows?   The compiler on the HP seems to give errors on re-
    declarations of variables, while the Sun/Vax compiler would only give
    warnings.  In the case of gated there were no warnings on the Vax/Sun,
    but there are redefined variables on the HP.  Very strange...

+
+>                               I finally got it to work by including the
+>    full pathname of /usr/lib/libBSD.a to be compiled with the other object
+>    files.  The "-lBSD" argument to cc didn't work, even though my reading
+>    of the cc man page indicates that it should.
+
+Where on the cc command line did you place the -lBSD option?  This
+option is simply a shorthand for /usr/lib/libBSD.a, which would show
+up at the same point in the command line.  Thus the option usually must
+go at the end of the command line (unlike normal option syntax), since
+the linker only extracts from a library .o files that resolve unresolved
+references from files preceding it on the command line.  This is
+common to all implementations I know of, but probably not explained
+well in the manual.

    Ha, I did finally figure this out.  I kept moving that sucker around
    until it worked, and indeed it did have to be at the end of the command
    line.  After figuring this out I read the man page again.  They do attempt
    to explain it by saying something about "undeclared references are only
    looked up when they are encountered in the program, so placement of
    the -l option is critical".  What they should have said is something
    like "the -l should be the last argument on the line."
----------------------------------------------------------------
Robert Allen, robert@spam.istc.sri.com	   "It's the last of the
415-859-2143 (work phone, days)		    V8 Interceptors Max!"
----------------------------------------------------------------