RSILVERMAN@eagle.wesleyan.edu (Richard Silverman) (07/13/89)
Hello, all...
I am trying to get CAP running on an AT&T 3B2 running System V R3.1.
With some minor modifications, all the libraries compiled just fine. When
building the sample programs, however, I have a problem. lwpr.c compiles
with no problem, but when I attempt to link it, the Streams system calls
getmsg, putmsg and sigset are not found. As far as I understand it: CAP
depends on the BSD socket-style network interface. This is provided by the
WIN/3B networking library libnet.a; these calls resolve properly. This library,
in turn, relies on the Streams transport interface defined in libnsl_s.a
(t_bind, t_open, etc.). These calls resolve, also -- except putmsg and getmsg,
even though a dump of the nsl library shows the symbols are there!
Confused, I stepped back to try a test. According to the Streams
programmer's guide, all I need to do to use the transport interface is to
link to libnsl_s.a. However, if I take this code:
main ()
{
getmsg();
}
and compile it with "cc test.c -lnsl_s", I get the same problem: getmsg is
not found. Now I'm really confused. I have restored libnsl_s.a from the
original release 3.1 upgrade disks; no help. Can anyone out there shed some
light?
Richard Silverman
arpa: rsilverman@eagle.wesleyan.edu Computing Center
bitnet: rsilverman@wesleyan Wesleyan University
CIS: [72727,453] Middletown, CT 06457larry@hcr.UUCP (Larry Philps) (07/14/89)
In article <20228@adm.BRL.MIL> RSILVERMAN@eagle.wesleyan.edu writes: > ... > I am trying to get CAP running on an AT&T 3B2 running System V R3.1. >With some minor modifications, all the libraries compiled just fine. When >building the sample programs, however, I have a problem. lwpr.c compiles >with no problem, but when I attempt to link it, the Streams system calls >getmsg, putmsg and sigset are not found. > ... >main () >{ > getmsg(); >} > >and compile it with "cc test.c -lnsl_s", I get the same problem: getmsg is >not found. Putmsg, getmsg and sigset are system calls under SYSV R3. So, they will be resolved by the system call stubs in libc.a. They should not be defined in the nsl_s library, only called from there. Have you modified libc lately? Why not try restoring libc and friends from the original distribution then try it again. Don't forget there are shared library versions also. Larry Philps HCR Corporation 130 Bloor St. West, 10th floor Toronto, Ontario. M5S 1N5 (416) 922-1937 {utzoo,utcsri,uunet}!hcr!larry
friedl@vsi.COM (Stephen J. Friedl) (07/16/89)
In article <20228@adm.BRL.MIL> RSILVERMAN@eagle.wesleyan.edu writes: > > I am trying to get CAP running on an AT&T 3B2 running System V R3.1. > ... but when I attempt to link it, the Streams system calls getmsg, > putmsg and sigset are not found. In article <1410@hcr.UUCP>, larry@hcr.UUCP (Larry Philps) writes: > > Putmsg, getmsg and sigset are system calls under SYSV R3. So, they will be > resolved by the system call stubs in libc.a. This reveals an unfortunate aspect of the 3B world. Compilers are packaged separately from operating systems, and most of the libraries (i.e., libc.a) live with the compiler. Upgrading to a more recent operating system (say, to SVR3.1) means that the operating system supports the new calls, but you can't use them unless your compiler has the hooks in libc.a (or unless you feel like writing some assembly language wrapper functions). You can check your compiler version with: cc -V I believe that Issues 2 and 3, plus C-FP+ are all packaged with Sys V Rel 2 libraries, and that CPLU4.1 and above have the SVR3 libraries. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl ---> vsi!bang!friedl <-- NEW "Hard work is a vastly overrated virtue" - my brother
pjh@mccc.UUCP (Pete Holsberg) (07/20/89)
cc -V tells me that both cc (actually, fpcc) and ld are "Release 1.0". That can't be referring to Unix SV R1.0, ---- can it??? -- Pete Holsberg -- Mercer College -- Trenton, NJ 08690 ...!rutgers!njin!princeton!njsmu!mccc!pjh