Xref: utzoo comp.unix.i386:3369 comp.sys.att:8967
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386,comp.sys.att
Subject: Re: HELLLLLP!  failing to build kernel for AT&T Voice Power board under ISC
Keywords: ISC 386/ix, Unix, kernel, speech boards/equipment
Message-ID: <1990Mar7.135103.6200@virtech.uucp>
Date: 7 Mar 90 13:51:03 GMT
References: <8648@bunny.GTE.COM>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 42

In article <8648@bunny.GTE.COM> jdg0@GTE.COM (Jose Diaz-Gonzalez) writes:
>I guess the subject line says it all.  I'm running Interactive's 386/ix 
>release 2.0.2.  I'm having problems while the Install script runs the 
>idbuild.  The system is not finding the following symbols: sxtopen, and 
>linkTable.  I did an nm on the Driver.o component of the /etc/conf/pack.d/sxt 
>and there is an address for this routine there.  However my /unix only has 
>references to sxtin and sxtout.  I suspect that I must have a way of linking 

This is because you do not have the sxt device configured into the kernel.
Edit the /etc/conf/sdevice.d/sxt file and change the N in column 2 to a Y
and then you will get what you need.

The reason for sxtin and sxtout in the kernel is because of the mechanism used
to stub out drivers that are not being used.  The /etc/conf/pack.d/sxt/stubs.c
has stub out routines for these functions and the rebuild software will
automatically compile and use stubs.c as opposed to Driver.o when the sdevice
file says the driver is not to be configured into the kernel.

The AT&T documentation should have specified that the sxt devices must be
configured to use the product.

>these two together to solve this problem but I don't know how.  But what 
>about the linkTable symbol?  There is nothing remotely resembling this name 
>in /unix.

There is an entry with such a name in /etc/conf/pack.d/sxt/Driver.o.

>Isn't ISC's 386/ix supposed to be binary compatible with AT&T's 
>System V/386?

Binary compatibility does not mean kernel compatibility (although that does
not seem to matter in this case).  Whenever you add a new driver it is
possible that the driver depends upon some undocumented features of a
specific kernel, or conflicts with someone elses driver and therefore can't
be used everywhere.  Like I sait, this doesn't seem to be the case with
your problem.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170