robert@spam.istc.sri.com (04/13/88)
I'm in the process of porting some software from a Sun 3/75 to an
HP 9000/300. 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. I've in-
cluded below what differnces I've noted thus far, which are by no means
the last. Several problems revolve around the lack of many files which
are normally in /usr/include/netinet.
What's different between the HP and Sun
---------------------------------------
1. /usr/include/sys/time.h exists on the Sun but doesn't on the HP.
It was deleted and /usr/include/time.h was used exclusively.
2. sys/ttychars.h exists on the Sun but doesn't on the HP. It was
deleted and /usr/include/sys/termio.h was used.
3. /usr/include/sys/ttydev.h exists on the Sun but doesn't on the HP,
it was simply deleted from the gated Makefile.
4. /usr/include/netinet/in_systm.h exists on the Sun but not on the HP.
It is the first of several netinet files which I cannot find on the
HP.
In addition, I've ported some code which uses TCP sockets for IPC.
I tried to use the libBSD.a to get the bzero, et. al. functions, but
couldn't. The diagnostic from the HP C compiler complained about un-
resolved globals (bzero). 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. Any help with this problem
as well as the missing files mentioned above would be of great help.
Thanks,
----------------------------------------------------------------
Robert Allen, robert@spam.istc.sri.com
415-859-2143 (work phone, days)
----------------------------------------------------------------rml@hpfcdc.HP.COM (Bob Lenk) (04/20/88)
> 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). > 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. Bob Lenk {ihnp4, hplabs}!hpfcla!rml rml%hpfcla@hplabs.hp.com
robert@milk10..istc.sri.com (Robert Allen) (04/22/88)
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!"
----------------------------------------------------------------