Партнёры:
Хостинг:
Archive-name: unix-faq/unixware/developer
Posting-Frequency: monthly
Last-modified: June 6, 1997
Version: 2.14
UnixWare╝ Frequently Asked Questions (Developer)
This is the Developer section of the UnixWare Frequently Asked Questions
file maintained on the Internet for the Usenet newsgroup
comp.unix.unixware.misc. Its maintainer is Andrew Josey
(andrew(a)tamarix.demon.co.uk). Suggestions and contributions are always
welcome.
This document and the other FAQ files may be found on the world wide web
at http://www.freebird.org/faq/
This document may also be obtained by anonymous ftp from the freebird
archive at
ftp.freebird.org:/unixware/freebird/hints/FAQ/developer
ftp1.freebird.org:/pub/mirror/freebird/hints/FAQ/developer
ftp2.freebird.org:/pub/unixware/freebird/hints/FAQ/developer
Small print: This file is Copyright 1997 freebird.org. Permission is
granted for copying for non-commercial use. Many proper names of
companies and software mentioned in these files are trademarks of their
respective owners. All views are those of the individual contributors
and not of their employers.
This article is posted monthly around the middle of the month. For more
information about the files which compose the total UnixWare FAQ, see
the "FAQ Overview" file posted regularly on the Internet newsgroup
comp.unix.unixware.misc.
INTRODUCTION
The Developer section covers aspects of the UnixWare 1.1.x and UnixWare 2.x
SDK. It also covers general concerns for anyone writing software for the
UnixWare operating system.
TABLE OF CONTENTS
D0) How do I get ahold of UnixWare Developer Support?
D1) Is UnixWare BSD compatible?
D2) Is there a C++ compiler for UnixWare 1.1?
D3) What does the UnixWare 2.0 SDK contain?
D4) Where is the ccs package on UnixWare 2.0?
D5) Where is the documentation for the UnixWare SDK?
D6) What books are there on UnixWare programming?
D7) Where are the man pages for the Standard C functions?
D8) Are there alternative SDKs to the UnixWare SDK for developers?
D9) How do I correctly use the UCB compatibility libraries?
D10) In what library is <undefined symbol> defined?
D11) In what library is regex() and regcmp() defined?
D12) In what library is XmbTextListToTextProperty defined?
D13) What libraries do I need to include for X applications?
D14) What libraries do I need to include for socket applications?
D15) How do I compile the sample Motif applications?
D16) Why do I get memory errors while building applications?
D17) I don't like the new Motif look and feel, How do I get the old one?
D18) How come I keep on getting as_dup proc failures?
D19) How do I get the C compiler to accept C++ style comments?
D20) How do I increase the number of socket connections for my application?
D21) How do I run debug on a SUID root program?
D22) Why do I get Driver without "f" flag not supported?
D23) Why can't I get my SUID root program to work?
D24) Why do I get a symbol error in librpcsvc.a on UnixWare 1.1?
D25) How do I get kdb output to go to a tty?
D26) Why do I have this library dtruntime.so.1 on UnixWare 2?
D27) I included all the necessary libraries, why do I still get unresolved
symbols?
D28) How come I can't get some Motif keyboard mappings to work?
D29) Why do I get a bad Makefile from xmkmf on UnixWare 2.0?
D30) How do I get cc to place object files in specific directories?
D31) Why does the open() call block when I try opening the serial port device?
D32) How do I compile tin?
D33) How do I compile emacs?
D34) How do I compile Perl 5?
D35) Where can I get audio software for UnixWare ?
D36) Where can I get the GNU debugger (gdb) for UnixWare 2?
D37) How can I debug an application without the source code?
D38) When I link I can 't find the syslog routines, what should I do?
D39) When I link I can 't find the strcasecmp routine?
D40) When I link I can 't find the alloca routine?
D41) How do I make a pkgmk add-on package?
D42) How to build binaries on UnixWare to run on other SVR4 systems such
as Solaris x86?
D43) How do I display files open to UnixWare processes?
Subject: D0) How do I get ahold of UnixWare Developer Support?
The SCO Developer programme can be reached on 1-800-SCO-UNIX in North America,
for the UK and International customers call SCO on +44 1923 816344.
As a member of the developer programme you get 5 free technical support
questions among other benefits - see http://www.sco.com/Developers
for info on the Developer programmes.
Subject: D1) Is UnixWare BSD compatible?
Yes, partially at the source level, No at the binary level.
SVR4.0 was created by joint venture with AT&T Bell Labs (then to become
USL) with Sun and SCO. The result remained very System-V, but what Sun
contributed was the ability to *compile* BSD-based code, even though
there was usually some tweaks necessary regarding libraries to include.
You will notice that in both major versions of UnixWare (1.1 and 2.x),
you can use /usr/ucb/cc to envoke the BSD compatible compiler & linker
that knows to link with the BSD-style libraries, which were themselves
compiled from calls to the standard Sys-V libraries (See
section D9 below).
Subject: D2) Is there a C++ compiler for UnixWare 1.1?
(Note the ordering information needs to be updated in the
light of the transfer of the UnixWare business to SCO ,
that information has been requested).
The C++ Compilation System 2.0 for UnixWare 1.1 is available for the
suggested retail price of U.S. $99 in CD ROM and QIC-24 tape formats.
To order in the U.S. or Canada, call 1-800-457-1767 or fax (317)
364-8888. Outside North America, call +31-55-384279 or fax
+31-55-434455.
An alternative is Comeau C++:
Comeau C++ 4.0 is a major feature upgrade of Comeau C++, including most
1996 ANSI/ISO C++ decisions: enhanced templates, exception handling, RTTI,
namespaces, new casts, etc. Comeau C++ is one of the earliest C++ compilers
and it provides solid and robust fundamental language features. It is
available for a number of platforms including UNIXWARE, SCO, LINUX, SunOS,
and Solaris. Comeau is a member of the ANSI/ISO C++ and C committees and
can be reached via sales@comeaucomputing.com, via phone at 718-945-0009 or
through their WEB site at http://www.comeaucomputing.com.
Subject: D3) What does the UnixWare 2.0 SDK contain?
1) C++ compiler with templates (C compiler is part of the AS and PE)
2) Enhanced Graphical debugger
3) Motif development tools (sorry, no GUI builder).
4) Network client/server developer tools {so what's new :-) }.
5) Online documentation through Dynatext.
6) Driver development tools including sample driver source.
7) Integrated window development tools
8) Software Packaging Tools
9) Kernel Debugger
10) Enhanced performance tools and profilers
11) Multithreaded application development
Subject: D4) Where is the ccs package on UnixWare 2.x?
The ccs package is no longer a part of the UnixWare SDK, but instead has
been included on the UnixWare AS and PE media. This is to facilitate
support for third- party SDKs and other software such as databases that
need the C compiler present to function. Even though this does give you
the C compiler, it does not give you all the components of the SDK such
as the debugger, include files, and miscellaneous static libraries. So
for a full development environment, an SDK is still considered
essential.
Note that you need to install the ccs package from your AS or PE media
prior to installing the SDK, or YOU WILL NOT be able to install the C++
compiler.
Subject: D5) Where is the documentation for the UnixWare SDK?
UnixWare 2.01 includes all the UnixWare SDK documentation and provides
it through the online documentation system of UnixWare 2.01. Printed
versions of the SDK Documentation are available in English only from:
Hart Graphics for the Novell Fulfillment Department
P.O. Box 141805
Austin, TX, USA 78714-9783
Or courier to:
Hart Graphics for the Novell Fulfillment Department
3106 Longhorn Blvd.
Austin, TX, USA 78758
Country Voice FAX
Australia 0014-800-128-411 0014-800-124-233
Canada 1-800-366-3892 1-800-826-5399
Singapore 800-1100-073 800-1100-088
U.S. 1-800-336-3892 1-800-826-5399
All others U.S. Country Code U.S. Country Code
+512/834-6905 +512/834-8901
Group 6 Basic Software Development US$ 125.00
Group 7 Networking Development US$ 95.00
Group 8 Windowing Development US$ 95.00
Group 9 C++ Development US$ 55.00
Group 10 IHV Development (drivers) US$ 115.00
Group 11 OSAPI Reference US$ 95.00
Group 12 NetWare Lib. Ref. for C US$ 125.00
Group 13 Motif Reference Manual US$ 75.00
Group 14 Additional SDK Reference US$ 75.00
Note: These prices do not include Shipping & Handling, or Tax.
Subject: D6) What books are there on UnixWare programming?
No UNIX programmer should be caught without the Stevens books:
Advanced Programming in the UNIX Environment
W. Richard Stevens
Addison-Wesley, 1992
ISBN 0-201-56317-7
UNIX Network Programming
W. Richard Stevens
Prentice Hall, 1990
ISBN 0-13-949876-1
Donald Lewine's POSIX programming guide is also indispensable as a
reference for "which standard defines what API?" kind of questions:
POSIX Programmer's Guide
Donald Lewine
O'Reilly and Associates, Inc.
ISBN 0-937175-73-0
You can also checkout Go Solo 2 - The Authorized Guide to Version 2
of The Single UNIX Specification which contains the standard
UNIX manuals (from The Open Group) on CD-ROM in html and PDF
(see http://www.rdg.opengroup.org/unix/gosolo2).
Subject: D7) Where are the man pages for the Standard C functions?
Just use the man -k command.
Subject: D8) Are there alternative SDKs to the UnixWare SDK for developers?
Yes, there are many options, and the number is increasing. The first
option developers generally try is using the GNU gcc compiler and other
GNU tools. The GNU tools are available from several sources. The first
place to try is ftp.freebird.org or any of its mirror sites. Here you can
get packaged binaries. The second is to get them from a CD-ROM
distribution such as the Prime Time Freeware Tools and Toys for UnixWare
or the Walnut Creek SVR4 (UnixWare) CD-ROM. These CDs include many
useful utilities that any developer would find handy. The third is to
get source from the Free Software Foundation or any of the many CD-ROMs
and build the binaries yourself.
Scott Raney <raney@metacard.com> writes:
MetaCard is a complete GUI development environment that includes a
graphical interface builder and a high-performance VHLL (Very High
Level Language). With MetaCard both novice and professional
developers can build graphical applications more rapidly than is
possible with other tools. Email info@metacard.com or see
http://www.metacard.com for more information.
There are many third party compilers available for UnixWare, and if the
vendors contact me I will include them in the FAQ.
Subject: D9) How do I correctly use the UCB compatibility libraries?
There are two problems that are typically encountered when
compiling/linking code that uses Berkley-isms:
* Undefined symbols at link time
* Incompatibilities between the SysV header files and the UCB libraries
C code using Berkley-isms such as index/rindex will generate "undefined
symbol" messages for each of the BSD-specific functions. To get around
this, you have one of two options:
* Option A: Straight UCB compile
Compile with the "UCB" compiler (/usr/ucb/cc). This is actually a shell
script wrapper around the standard C compiler (/usr/ccs/bin/cc) that
sets up the necessary #include and library paths. This is the path to
take if you want a more "pure" BSD environment for your development.
* Option B: SysV compile with Berkeley extensions
If you want a SysV environment, but need to link in some functions
only available in the BSD library (eg, you'll replace gethostname() with
uname() later), simply link in the UCB libraries _after_ the standard
(SysV) libraries. For example:
cc -o foo foo.c -lc -L /usr/ucblib -lucb
Note the order of the library specifications, and that "-lc" should
precede the UCB library specification to resolve all possible synonyms
against the SysV library, rather than the BSD library.
Be careful exercising option (b), however. Merely linking against the
UCB library, without the preceding "-lc", will cause code to be compiled
against the SysV #include files (located in /usr/include) and then
linked against the UCB libraries:
cc -o foo foo.c -L /usr/ucblib -lucb # Don't do this
(Note that an implicit "-lc" is appended to the command line.)
Differences in such things as structure sizes between the SysV #includes
and the UCB libraries can wreak all kinds of havoc - as Jim Vlcek
discovered in just this fashion when trying to use setjmp in a source
module that also called some UCB functions. One way to get around this
is to insert a "-I /usr/ucbinclude" directive into the command line, but
this is essentially the effect of using /usr/ucb/cc.
Gordon W. Ross <gwr@mc.com> wrote:
I just wanted to mention here that most people I have helped with
porting problems related to the dirent or directory libraries have
caused their own problems by incorrectly using the UCB library.
The directory(3) routines in the UCB library only work with the
header files in /usr/ucbinclude so if you fail to put that in
your include path and just link with -lucb you end up with
seriously broken programs. The stuff in /usr/ucbinclude/ and
/usr/ucblib/ was meant to be used by /usr/ucb/cc only, and
when used that way it (mostly) works. I have usually found it
easiest to just stay away from the UCB library entirely.
I would advise others to do the same. (The UCB library has
well known problems in signal and some dbm functions.)
Robert Withrow (witr@rwwa.com) wrote:
In addition, checking the following things will almost always yield a
working port for any reasonably `well behaved program':
1 Replace bcopy et.al with the apropriate memcpy functions...
#define bcopy(b1,b2,len) memmove((b2), (b1), (size_t)(len))
#define bzero(b,len) memset((b), 0, (size_t)(len))
#define bcmp(b1,b2,len) memcmp((b1), (b2), (size_t)(len))
2 Replace index and rindex approprately:
#define index(a,b) strchr((a),(b))
#define rindex(a,b) strrchr((a),(b))
3 Don't use the SVR4 library's signal() routine,
[use sigaction instead ...]
/* Reliable signals */
/* This was taken from Stevens... */
#include <signal.h>
typedef void Sigfunc(int);
Sigfunc *signal(int signo, Sigfunc *func)
{
struct sigaction act, oact;
act.sa_handler = func;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
if (signo != SIGALRM) {
act.sa_flags |= SA_ESTART;
}
if (sigaction(signo, &act, &oact) < 0)
return(SIG_ERR);
return(oact.sa_handler);
}
4 Replace random with lrand
#define random() lrand48()
#define srandom(seed) srand48((seed))
5 Replace the bsd readdir code with the Posix code (requires changing an
include file and a declaration usually, but also perhaps a symbol with a
strlen.)
6 Replace wait3 and wait4 with posix wait code. This is complicated
because some code *writes* into the values that posix only provides read
access to.
Rick Richardson (rick@digibd.com) wrote:
Its much easier to port stuff than most people think.
I've found that 99.99% of applications with BSDisms can be ported
by simply compiling normally, but linking with -lc -lucb. This
resolves the SVR4 C library first, avoiding problems with dirent
and the like, but also lets you pick up any BSD-isms like
random(), index(), etc.
Really, its painless.
Other advice for porting applications :
What to use instead of gethostname, getdtablesize, getpagesize?
(a) gethostname
This can be replaced by using the sysinfo(2) routine.
#include <sys/systeminfo.h>
....
char buf[MAXHOSTNAME];
/* BSD code was: */
/* if (gethostname(buf, sizeof(buf)) < 0) { */
if (sysinfo (SI_HOSTNAME, buf, sizeof(buf)) < 0) {
perror("SI_HOSTNAME);
exit(ERROR);
}
(b) getdtablesize
This can be replaced by the sysconf(2) routine
#include <unistd.h>
....
long tablesize;
#ifdef _SC_OPEN_MAX /* POSIX define*/
tablesize = sysconf (_SC_OPEN_MAX);
#else /* BSD code */
tablesize = getdtablesize();
#endif
(c) getpagesize
This can be replaced with a call to sysconf(2)
#include <unistd.h>
....
long pagesize;
#ifdef _SC_PAGE_SIZE /* X/Open define*/
pagesize = sysconf (_SC_PAGE_SIZE);
#else /* BSD code */
pagesize = getpagesize();
#endif
Subject: D10) In what library is <undefined symbol> defined?
The command 'nm' can be used to examine the contents of library files,
or use the following script to automate the process.
--- Cut here and save to "who_defines", then "chmod +x who_defines"---
#!/bin/sh
if [ $# -ne 1 ]
then
echo "Usage: who_defines function_name" >&2
exit 1
fi
# You may need to add library directories to this list.
LIBDIRS="
/usr/lib
/usr/ccs/lib
/usr/X/lib
/usr/ucblib"
for dir in $LIBDIRS
do
for lib in $dir/*.a $dir/*.so
do
if [ -r "$lib" ]
then
nm -px $lib | sed -n '/T \<'$1'\>/p' 2>/dev/null |
while read ans
do
echo $lib:$ans
done
fi
done
done
--- End of "who_defines" ---
To determine where a symbol (eg, bind) is defined:
% who_defines bind
/usr/lib/libsocket.a:0x000000c0 T bind
/usr/lib/libsocket.so:0x00008050 T bind
Note that, as above, you will often get multiple answers. Here, we see
that bind itself is in the socket directory (the .a and .so are the
static and dynamic libraries, respectively). The library name is the
path that precedes the colon; your ld command line should thus include
the entry:
-lsocket
Subject: D11) In what library is regex() and regcmp() defined?
The functions regex() and regcmp() are located in the general function library
/usr/ccs/lib/libgen.a and can be included by using the option -lgen to cc.
Subject: D12) In what library is XmbTextListToTextProperty defined?
This function as well (as the function XmbTextPropertyToTextList()) is
defined in the library /usr/X/lib/libXIM.so on UnixWare 1.1. This
should not be a problem on UnixWare 2.0.
Subject: D13) What libraries do I need to include for X applications?
This is how the sample application periodic was linked:
$ cc -o periodic periodic.o -O -Xa -T 0x8300000 -L//usr/X/lib
/usr/X/lib/libMrm.so /usr/X/lib/libXm.so -lXt -lXext -lX11 -lgen -lnsl
-z nodefs
Subject: D14) What libraries do I need to include for socket applications?
Socket applications need to include the sockets library and the
networking support library:
$ cc -o foo foo.c -lsocket -lnsl
Subject: D15) How do I compile the sample Motif applications?
The simple way to compile one of the sample Motif applications is to
first copy it to some local working directory to avoid permission errors
on the files:
$ cp -r /usr/X/lib/motifdemos/periodic periodic
Then cd into the periodic directory:
$ cd periodic
Run xmkmf to convert the Imakefile into a Makefile (See D29 first):
$ xmkmf
imake -DUseInstalled -I/usr/X/lib/config
Then run make:
$ make
/bin/rm -f periodic.o
cc -c -O -Xa -I. -I./X11 -I./X11 -I///usr/X/include
-I///usr/X/include/X11
-I/usr/include -I//usr/X/include -I. -DSVR4 -DSYSV386 -DI18N
-DFUNCPROTO=15 -DNARROWPROTO -DLIBDIR=\"/usr/X/lib\"
-DDESTDIR=\"/usr/X\" periodic.c
/bin/rm -f periodic
cc -o periodic periodic.o -O -Xa -T 0x8300000 -L//usr/X/lib
/usr/X/lib/libMrm.so /usr/X/lib/libXm.so -lXt -lXext -lX11
-lgen -lnsl -z nodefs
Then run:
$ ./periodic
Subject: D16) Why do I get memory errors while building applications?
The first potential problem is running into user process limits which
are controlled by the following tunables:.
SDATLIM
HDATLIM
SSTKLIM
HSTKLIM
SVMMLIM
HVMMLIM
These may need to be increased so that enough memory resources are
available to build very large applications.
The second potential problem could be a lack of swap space. This can be
checked by using the swap command. Remember that swap is a dynamic
thing so just running the swap command after a failed compile does not
tell the story of what is happening during the compile. On UnixWare 2,
you can use the real time performance monitor (rtpm) or the GUI System
Monitor to watch what is going on. More swap can be added by swapping
to a file which should be covered in the administration FAQ.
On UnixWare 2.0, there is also the possibility that you are running out
of /tmp file space since this defaults to a memfs. Since the compiler
heavily uses /tmp, this filesystem may need to be increased by editing
the /etc/vfstab file entry for /tmp, or not using a memfs for /tmp at
all.
Subject: D17) I don't like the new Motif look and feel, How do I get the old
one?
Some developers have expressed the desire to have Motif version 1.2.3
under UnixWare 2.0 have the older look and feel of Motif version 1.2.2.
Following is a developers note:
> ... the look and feel of the XmToggleButton
> is vastly different under UW 2.0 than those of the standard
> Motif version. The XmToggleButton in radio mode is a round
> circle instead of the standard diamond shape. The non-radio
> mode XmToggleButton displays a check mark inside the square
> under UW 2.0. IMHO this is ugly.
This is the standard look and feel for CDE. Sun, HP, IBM, DEC, Novell,
Fujitsu, Hitachi, and other vendors are or will soon be shipping this
same Motif (same source code). While UnixWare 2.0 does not include the
CDE desktop, it does include the CDE Motif implementation.
Furthermore, this user interface design change was in response to
_significant_ user complaints about the old look. Hundreds of users have
complained that the old visuals were not visibly distinctive, leaving
them unsure which toggles were set and which were not. The new visuals
are decidedly better, in the humble opinion of customers, user interface
designers, and the vendors shipping CDE.
> The question I have is
> WHY OH WHY did Novell do this type of thing? The Motif look
> and feel is supposed to be standard across all platforms.
> What Novell did to Motif is gratuitous, and a disservice to
> the efforts of a standard.
Nope, just the opposite. We participated in the standards activities
that lead to this change.
In any case, one can get the old look (diamonds, no-checks) by setting
these resources:
*enableToggleVisual: false # use the diamond/empty-square visuals
*enableToggleColor: false # use "select" color, instead of highlight color
This will restore the original, hard-to-distinguish visuals.
The complete set:
*enableToggleVisual: {true|false}
# use the diamond/empty-square visuals
*enableToggleColor: {true|false}
# use "select" color, instead of highlight color for selected toggles
*enableBtn1Transfer: {button2_transfer|true|false}
# true == Button 2 is ADJUST, Button 1 is TRANSFER
# button2_transfer, Button 2 is TRANSFER, Button 1 is drag and drop
*enableButtonTab: {true|false}
# TAB moves among pushbuttons in tab groups, e.g. Apply/Reset/Cancel
*enableDefaultButton: {true|false}
# shows button highlight inside the default-ring on the default button
*enableDragIcon: {true|false}
# uses better default icons (visuals) for drag and drop
*enableEtchedInMenu: {true|false}
# shows menu buttons as "pressed in" rather than "pushed out"
*enableMenuInCascade: {true|false}
# can use the Button 3 to pull down menus on menu bars
*enableMultiKeyBindings:{true|false}
# enable use of additional key bindings (e.g. Sun's Cut/Copy/Paste)
In all cases, a value of "false" gets the original (old) Motif behavior.
For UW 2.0, the default .Xdefaults file gives "true" for all these,
except the third ("button2_transfer").
Subject: D18) How come I keep getting as_dup proc failures?
UnixWare 1.1:
These errors are generally caused by memory problems (as opposed to
newproc pid_assign errors, which are generally due to low values of the
NPROC and MAXUP tunables). These errors could be caused by insufficient
RAM, swap space or by processes which take up too much memory.
Processes which do many time calls may be prone to the localtime memory
leak and might get very large and thus take up a lot of memory. Also,
processes which do successive mallocs and frees may be prone to a
problem with free (where memory does not get correctly returned to the
system) and may also get very large and use too much memory.
To find whether there are processes running which have grown too large,
enter:
ls -l /proc
This will list all processes (by pid) and how much memory they take.
Aside from adding more RAM or swap, if there are processes which are
taking up an inordinately large amount of memory, try applying PTF174
(localtime memory leak) and/or PTF161 (problem with free). These ptf's
contain updates to shared object libraries and thus they should be able
to be applied to the run-time system. The app should not have to be
re-compiled.
NOTE: ptf174 is contained in Update 1.1.3.
UnixWare 2.0:
I have never heard of anyone getting this under UnixWare 2.0, but the
same memory problems would be at fault.
Subject: D19) How do I get the C compiler to accept C++ style comments?
By supplying the following options on the cc command line, you can get
cc to accept C++ style comments:
cc -W0,-B foo.c
Subject: D20) How do I increase the number of socket connections for my
application?
UnixWare 1.1:
To do this you first must edit the /etc/conf/sdevice.d/sockmod system
file and increase the number in the third field. Normally this defaults
to 128. The system maximum for this is about 256 connections due to a
limitation in the library libc.so. After this value has been increased,
the kernel must be rebuilt and the system rebooted. Also, the kernel
tunable NUMTIM might need to be increased to allow for the greater
number of streams modules required by the socket interface. For every
socket connection opened there is an associated file descriptor. If the
user executes the command 'ulimit -a' he/she will see that this defaults
to 64. In order to get more than 64 connections the associated tunables
SFNOLIM and HFNOLIM must be increased. Because of the limitations in
the library libc that were described previously, there isn't much need
to increase this beyond 256. There is an upper limit to the number of
connections allowed due to kernel memory allocation limitations. Kernel
memory must exist in the less than 16MB memory range due to
historical/architectural reasons. This means that the kernel image,
drivers, and kernel buffers (including streams buffers) live in the less
than 16MB memory range. This creates the limitation on the number of
connections based on how much memory can be acquired to maintain these
connections. This has implications for machines with less than 16 MB of
RAM, i.e., more RAM may be necessary to increase the number of
connections. I was successful in getting 197 socket connections, and
had a developer get around 230.
Now with the number of connections increased, if the applications being
run are things such as telnet or ftp, the /etc/inet/inetd.conf
configuration needs to be such that the required number of server
daemons can be started such as in.telnetd or in.ftpd.
Note: after the initial release of this TID, I have had some developers
in Novell USG state that they believe there should not be a limitation
in the number of connections through libc. So it may be possible to
increase this to a value greater than 256.
UnixWare 2.0:
There are several causes that lead to not having enough socket connections:
1) The ulimit values may be limiting the number of open files allowed.
2) For UNIX Domain sockets, the third field in
/etc/conf/sdevice.d/ticots is set too low.
3) For Internet Domain sockets, the third field in
/etc/conf/sdevice.d/tcp is set too low.
First, increase the number of open files a process is allowed to have by
tuning the SFNOLIM system tunable. This can be done using the System
Tuner in the Admin_Tools folder on the desktop. (This value can also be
increased temporarily by typing "ulimit -n unlimited" as root.)
Second, for UNIX Domain sockets, increase the number in the third field
of /etc/conf/sdevice.d/ticots. Rebuild this module by typing "idbuild
-M ticots". For Internet Domain sockets, increase the number in the
third field of /etc/conf/sdevice.d/tcp. Rebuild this module by typing
"idbuild -M tcp".
Reboot the system.
Note: For this I increased the values to 1024, there appears to be no
upper limit on how many connections there can be.
Subject: D21) How do I run debug on a SUID root program?
When trying to run debug on a setuid program, the following error
message appears:
System error attempting to control process <pid>
Create failed: all resulting processes killed
This happens whether debug is run by the program owner (usually root) or
not. debug cannot be run by someone other than the program owner
(usually root) because then the person running the program could make
modifications to the program which are not explicitly allowed by
setuid.
The graphical version of debug cannot be run by the program owner
(usually root) because this person is generally not the same person
whose desktop debug will try to display on. By default, X does not
allow one user to display windows on another person's desktop.
To run the graphical version of debug on a setuid program:
1) xhost +
(This allows other users to display windows on your desktop).
2) su to the person who owns the setuid program.
3) run debug on the program.
Subject: D22) Why do I get Driver without "f" flag not supported?
This driver probably has a version 0 Master file and does not have an
"f" in the characteristics field (see man (4) Master). This means that
this driver is not a DDI/DKI compliant driver, and thus will not work on
UnixWare 2.0.
The solution is to modify the driver to be DDI/DKI compliant. This will
also guarantee that the driver will work on future releases of UnixWare.
Consult the Device Driver Reference Manual (DDI/DKI) in the Dynatext
Browser. It gives good detail on what is needed to be compliant, what
is supported, and what is not supported.
NOTE: We stated that UnixWare 1.1 drivers will run on UnixWare 2.0.
The actual situation is that DDI/DKI compliant 1.1 drivers (drivers
written for 1.1) will work on 2.0. The problem is that 1.1 supported a
lot of older driver interfaces, but this support is not in 2.0.
Developers need to become DDI/DKI compliant.
Subject: D23) Why can't I get my SUID root program to work?
The common situation is that a developer has a SUID application (The
effective user ID bit set) for a root owned application and it is unable
to locate dynamic libraries at runtime. The error would be something
like:
dynamic linker : xapplication : error opening libX11.so
Killed
This is common if the SUID root application is an X application.
This is a deliberate action to prevent a problem with security. If the
dynamic linker did not cause this to break on SUID programs a potential
security hole would occur. The security hole would be in the form that
the SUID program would use the LD_LIBRARY_PATH to search for dynamic
libraries needed. In a SUID program that path must be static. If the
library were located using the LD_LIBRARY_PATH then a user could
potentially create his own library that mimics a well known library.
This "imposter" library could have a deliberate security hole in it.
When the application tried to locate a library such as libX11.so and
went to the user's imposter library by using the LD_LIBRARY_PATH, the
security would have been compromised since the application may be owned
by root.
To prevent this security problem, SUID applications must have the path
to all libraries statically included. To do this the developer needs to
set the LD_RUN_PATH to point to all libraries needed by that application
prior to linking. By default SUID applications search for libraries in
/usr/lib, but if the application is an X application, all the X
libraries are in /usr/X/lib and these libraries would not be located if
the LD_RUN_PATH environment variable was not set prior to linking.
Subject: D24) Why do I get a symbol error in librpcsvc.a on UnixWare 1.1?
This library has a symbol table problem. When trying to link to the library
librpcsvc.a, the developer gets an error that this library is corrupt.
This library can be fixed by running the 'ar' command on it as root.
# ar -sr /usr/lib/librpcsvc.a
Subject: D25) How do I get kdb output to go to a tty?
The kdb command 'newterm' will let you change a kdb session to a tty.
All subsequent kdb sessions will then go to this same tty. Just make
sure there is a ttymon active on the tty before you do this.
The syntax on UnixWare 2.0 is "newterm <driver> <minor #>", so for
example "newterm iasy 2" will send output to /dev/tty01. For UnixWare
1.1 the syntax is a little different, but the effect is the same.
Another option which will force all console output to another device is
to edit the /stand/boot file and use the console parameter to indicate
another device. See the man page for boot(4) for parameter details and
the man page for boot(1) for information on the boot file itself.
Subject: D26) Why do I have the library dtruntime.so.1 on UnixWare 2?
Developers have noticed that several of the standard X libraries are
symbolically linked to the library /usr/X/desktop/dtruntime.so.1. What
is the reasoning behind this?
The reason for this library is as follows:
1) dtruntime is a library that is the combination of many of the X libraries
2) This was done to speed up X programs. It accomplishes this 2 ways: the
run-time linker has to do much, much less work at startup to resolve
symbols and locality tuning is more effective on one large object (as
opposed to many small ones) since there is a high correlation between
references to multiple libraries (e.g. Xtfunc always calls Xfunc).
3) There is no wasted space on a run-time system (a system with no SDK).
Simply, many libraries are link-edited to one and links are made to the
individual names. On a system with the SDK installed, 3 MB is wasted,
since we can't link the run-time libraries to the build libraries (i.e.
ZZZ.so.1 -> ZZZ.so).
4) Any programmer who uses the SDK will not see dtruntime unless he/she is
doing ls's around /usr/X (see #5).
5) One's binaries still say that the program requires libXt.so.5.0 to run.
It just happens to be that on our system, this file is a link to
dtruntime.
In fact, we took great effort in not "exposing the implementation"
so that executables will never be dependent on dtruntime and the ABI
is not violated.
6) Some have commented "what a hack".
This is, actually, an unhack. Novell realized that the illusion
of separate libraries was just that . . . so we put them together. The
beauty of the idea is that we can unlink the libraries at any time if
there was a reason to do so (see #5).
Subject: D27) I included all the necessary libraries, why do I still get
unresolved symbols?
Some developers have noticed that while linking an application on
UnixWare with the correct libraries, they still get unresolved symbols.
The libraries are even verified with the 'nm' command to contain the
needed symbols.
It has been noted that how files are specified on the cc command line
affects what libraries are searched and included.
The following command line will not work:
$ cc -lsocket -lnsl -lgen -o main.o main.c
Where this one will:
$ cc -o main.o main.c -lsocket -lnsl -lgen
Note that the libraries must be specified last. The reason for this is
because the first few options go to the C compiler, where the last
options go to the linker. Before someone states that this is broke,
this is actually done to be SVID/ABI compliant.
Subject: D28) Why can't I get some Motif keyboard mappings to work?
A Developer had an application that remapped keys on the keyboard in the
defaults file located in /usr/X/lib/app-defaults under UnixWare 1.1.3
and it worked fine. When moved to UnixWare 2.01, the application can no
longer map the keys correctly.
The problem here is that in going from UnixWare 1.x to UnixWare 2.x the
Motif library changed from 1.1 to 1.2. With this library change, the
concept of Virtual Key bindings was introduced which adds a level of
abstraction between actual Key events and what applications act on.
Client side generated osfXXX key events are then translated to actual
key events at the Server level.
When an application overloads Raw Key events, there's no guarantee that
Motif will not overload those.
In a test program I was able to overload <Key>Home and <Key>End with no
problem but could not overload <Key>Insert. Changing the <Key>Insert to
<Key>osfInsert worked fine. In general the application should overload
the osfXXX events instead.
The developer needs to modify the translation table to overload
<Key>osfInsert <Key>osfBeginLine and <Key>osfEndLine instead of the
<Key>Insert, <Key>Home and <Key>End translations.
Subject: D29) Why do I get a bad Makefile from xmkmf on UnixWare 2.01?
During the building of periodic in the /usr/X/lib/motifdemos/periodic
directory, I get these problems:
$ cd periodic
$ ls -l
total 130
-r--r--r-- 1 darrend other 984 Jun 22 10:50 Imakefile
-r--r--r-- 1 darrend other 1127 Jun 22 10:50 Periodic.ad
-r--r--r-- 1 darrend other 18137 Jun 22 10:50 periodic.c
-r--r--r-- 1 darrend other 35962 Jun 22 10:50 periodic.uil
-r--r--r-- 1 darrend other 7381 Jun 22 10:50 periodic_local.uil
$ xmkmf
imake -DUseInstalled -I/usr/X/lib/config
$ make
/bin/rm -f periodic.o
cc -c -O -Xa -I. -I./X11 -I./X11 -I///usr/X/include
-I///usr/X/include/X
11 -I/usr/include -I//usr/X/include -I. -DSVR4 -DSYSV386 -DI18N
-DFUNCPROTO=15
-DNARROWPROTO -DLIBDIR=\"/usr/X/lib\" -DDESTDIR=\"/usr/X\" periodic.c
/bin/rm -f periodic
cc -o periodic periodic.o -O -Xa -T 0x8300000 -L//usr/X/lib
./lib/Mrm/libMrm.so ./lib/Xm/libXm.so -lXt -lXext -lX11 -lgen -lnsl
-z nodefs
UX:ld: ERROR: ./lib/Mrm/libMrm.so: fatal error: cannot open file for reading
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.
$
It appears that the Motif templates file in /usr/X/lib/config is
incorrect. You can get imake or xmkmf to work correctly if you fix the
file /usr/X/lib/config/Motif.tmpl with the following corrections.
Change:
MTOOLKITSRC = $(LIBSRC)/Xt
MWIDGETSRC = $(LIBSRC)/Xm
MRESOURCESRC = $(LIBSRC)/Mrm
To:
MTOOLKITSRC = /usr/X/lib
MWIDGETSRC = /usr/X/lib
MRESOURCESRC = /usr/X/lib
I suggest that you comment out the old lines like this:
/* MTOOLKITSRC = $(LIBSRC)/Xt */
/* MWIDGETSRC = $(LIBSRC)/Xm */
/* MRESOURCESRC = $(LIBSRC)/Mrm */
Note also that you will get a permissions error if you try to build this
application in that directory. I suggest making a local copy, as root
does not have the necessary environment for building this application
(No X references).
Subject: D30) How do I get cc to place object files in specific directories?
Developers using the C compiler cc need to place object files in
specific directories. Note that this feature is supported by some third
party compilers, e.g.
$ cc -c darren.c -o /tmp/darren.o
The SVID definition states that the -o option only applies to the
linker. Since using the -c option means the linker is never called,
this option will not work.
There is a workaround using the -Wa option to the compiler (see the cc
man page.)
$ cc -c darren.c -Wa,'-o/tmp/darren.o'
Note that I did not put a space after the -o option.
Subject: D31) Why does the open() call block when I try opening the serial
port device?
The general symptoms of this problem are:
1) I try to open the serial port device and the open() call blocks.
2) How can I bypass this insistence on having a modem carrier when I am not
talking to a modem?
3) I don't want O_NOBLOCK behavior for my serial device.
One solution involves making a special serial cable as follows:
You could loop 6, 8 and 20 at the Unix end to assert DCD.
Another solution involves opening the driver non-blocking. There is an
O_NDELAY flag or an O_NOBLOCK flag to open() which causes the open call
to succeed without waiting for carrier detect to be asserted. If you use
either of these modes, you can turn off the non blocking behavior,
since this is not the operating mode you may desire for the subsequent
read() and write() calls.
You use fcntl() after open() to turn off O_NDELAY (error checks omitted):
fd = open ( "/dev/tty01h", O_RDWR | O_NDELAY );
flags = fcntl ( fd, F_GETFL );
fcntl ( fd, F_SETFL, flags & ~O_NDELAY );
Subject: D32) How do I compile tin?
This should by now be a classic problem in compiling tin under UnixWare
(1.0 at least, I don't know if 1.1 fixed this particular bug).
When you're compiling tin, the make may fail on the first source file
with messages like the following:
"/usr/include/sys/termios.h", line 503: (struct) tag redeclared: winsize
active.c, line 615: warning: argument is incompatible with prototype: arg #4
active.c, line 616: warning: argument is incompatible with prototype: arg #4
make: fatal error.
If this occurs, you've encountered a bug in one of the UnixWare system
header files. You can do one of two things to compile tin under
UnixWare:
* Fix the header file. Change all occurrences of
_IO_PT_PTEM_H
to
_IO_PTEM_H
in the file /usr/include/sys/ptem.h.
<or>
* Hack the tin header file tin.h, which is what I did. At line 130 in
tin.h, you'll find two #include directives, <sys/ptem.h> and
<sys/tty.h>. Place the following #define between these two #includes:
#define _IO_PTEM_H
This works around the problem with the system header files, if you're
not excited about modifying them (or don't have su privileges).
Subject: D33) How do I compile emacs?
The UnixWare cc preprocessor (cc -P) doesn't work the same as
/usr/ccs/bin/cpp from the configure script. You have three options:
1) Use gcc. The GNU compiler groks the GNU configure file.
2) Use the UnixWare preprocessor /usr/ccs/bin/cpp directly.
3) Get the emacs binary as indicated in the FAQ.
Subject: D34) How do I compile Perl 5?
Note that Perl 5 source and binaries are now available from ftp.freebird.org
tye@fohnix.metronet.com (Tye McQueen) wrote:
Porting (aka Installing) Perl 5.x to UnixWare systems can be
confusing, but it need not be difficult. Here are some notes
to help you. I hope to make some of these notes obsolete in a
future release of Perl and to include the remaining ones in a
README.svr4 file in that distribution.
First, be sure you have Perl5.001m or later. You can fetch a copy
from:
ftp://ftp.metronet.com/pub/perl/source/perl5.001m.tar.gz
or many other places listed in the Perl meta-FAQ, which can be
found at:
http://www.khoros.unm.edu/staff/neilb/perl/metaFAQ/metaFAQ.html
or
ftp://ftp.khoros.unm.edu/pub/perl/metaFAQ.txt
I don't recommend trying to apply patches to a Perl5.000 or
Perl5.001 distribution; just fetch the full latest distribution.
Next, an easy way to build Perl successfully is simply:
1. $ mv -f config.sh config.sh.old
2. $ ./Configure -dsE
3. You can edit config.sh here (but don't do it this first time).
4. $ ./Configure -S
5. $ env LD_LIBRARY_PATH=`pwd` make
6. $ env LD_LIBRARY_PATH=`pwd` make test
7. Become "root", if you aren't already.
8. # env LD_LIBRARY_PATH=`pwd` make install
9. Answer "yes" that you want /usr/bin/perl set up.
I say "simply" because this method only asks you one question and I've
told you what the answer is. Yes, it is more steps than it should be.
You might want to save the last two steps until you are sure you
have everything configured the way you like. Please don't let the
"WHOA THERE!!!"s scare you. They are there for a reason and the
default answer ("yes") is what you want.
More advanced options
If you don't like the directories that Configure picks to install
things into, the simplest change is to add "-Dprefix=/usr/local" on
the end of Step 2 above (where "/usr/local" is the directory where
you want "bin/*", "lib/perl5/...", and possibly "man/*/*" to be
installed). ./Configure will pick /usr/local if it exists,
otherwise it will probably pick /opt.
You can also go back to Step 3 above and change the paths in config.sh
that you don't like (the Notes section has more hints on doing this).
There are even more options you can give to Configure to influence
what directories it picks, but I haven't tested those options so I
won't go into those switches here. You can type "./Configure -h" for
more information on switches that can be given to Configure.
If you want to use GNU CC to build Perl:
* Add "-Dcc=gcc" on the end of Step 2 above.
* Be sure to not use GNU AS, GNU LD, nor GNU LIBC.
* Make sure you installed GNU CC correctly, including the
"fix-includes" step.
* You may be able to use GNU's gdbm to emulate odbm and ndbm for the
ODBM_File and NDBM_File extensions, but I've seen reports of
problems (lock ups) with this under Linux.
I haven't installed gcc so I haven't tested this (these hints come
from problems others have had using GCC on other systems).
Possible problems
Building Perl on UnixWare 1.x then running on UnixWare 2.x
The most serious problem I am aware of is that a Perl executable
compiled on UnixWare 1.x may run on UnixWare 2.x but it will not
do I/O correctly. This is because Perl uses some "officially
non-standard" optimizations (that happen to port well to a wide
variety of UNIX systems) in order to get much faster I/O under many
circumstances.
If you really want one version of Perl that will run on both UnixWare
1.x and UnixWare 2.x, then you can disable these optimizations either
by adding "-Dd_stdiobase=undef" on the end of Step 2 above or by
going back to Step 3 above and changing d_stdiobase='define' to
d_stdiobase='undef' then continuing on with the rest of the steps. I
have tested both of these methods and am using such a version of Perl
under both UnixWare 1.1 and UnixWare 2.01.
If I don't find any problems with it I will update the hints/svr4.sh
file to do this automatically for UnixWare systems. I'll also see if
Novell or SCO will make this version available in "pkgadd" format.
File glob tests fail due to broken csh in UnixWare 1.1.4.
I have two reports that the version of csh included with UnixWare 1.1.4
is broken (which is the version of csh included in PTF2001 which fixes
memory leaks in csh). This will cause some of the "file glob" tests to
fail.
If this happens to you, you can get around the problem by going back
to Step 3 above and changing d_csh='define' to d_csh='undef' in
config.sh then continuing on with the remaining steps. You might also
want to check out my File::Glob module which does file globbing inside
Perl (http://www.metronet.com/~tye/glob.html).
Easy to break DynaLoader, ODBM_File, and NDBM_File.
You should be able to include Dynamic Loading along with both the
ODBM_File and NDBM_File extensions in Perl under SVR4. It is very easy
to run into problems using any of these three features under SVR4, but
if you follow the above instructions, then you shouldn't run into
these problems.
You won't get the ODBM_File nor NDBM_File extensions if you haven't
installed the "BSD Compatibility" package. This is because the dbm
routines are kept in /usr/ucblib/libucb.a and the ndbm routines are
kept in /usr/ucblib/libdbm.a and require /usr/ucblib/libucb.a.
This stuff is easy to break because all SVR4 systems (except UnixWare
2.x -- thanks Novell!) have a broken /usr/ucblib/libucb.a which will
often break programs that try to use it. The hints/svr4.sh file can
usually prevent problems by telling Perl to not use most of the
routines in libucb.a. The way hints/svr4.sh does this is why Configure
gives you all of those scary "WHOA THERE!!!" warnings.
You can use most (on UnixWare 2.x, all) of the BSD-compatibility
routines, if you want. I made the defaults to not use any of these
for several reasons.
* Prior to UnixWare 2.x, trying to ld with the floating point
routines from libucb.a (ecvt, gcvt, fcvt, etc.) resulted in
"undefined symbol" errors. If using them only in a dynamically
loaded extension, then these "unresolved external" errors might
not show up until you tried to use the extension.
* I worried that there could be SVR4.x systems with versions of
libucb.a where even more of these routines don't work.
* I don't believe that they add any functionality over the
corresponding native SVR4.x routines, even considering how Perl
knows how to use them. If anyone finds otherwise, please let us or
me know so that Perl can be fixed to use the SVR4.x routines more
effectively.
* I worry that they add some overhead, though probably not a great
amount.
Notes
Changing where Perl will be installed
Don't worry too much about all the stuff in config.sh that may not
make sense to you. You can just change the first part of any absolute
paths (those that start with "/") that appear between single quotes
(') after an equal sign (=). But don't change any of these "paths"
that point to files that already exist on your system (ie. only change
ones that point either to directories or to places that don't exist
yet). Save a copy of config.sh before you edit it in case you change
your mind.
Hint: When running the tests, set your locale to the C locale,
LANG=C
export LANG
Subject D35) Where can I get audio software for UnixWare ?
Voxware driver support for UnixWare 1.x and 2.x can
be found on ftp.freebird.org:/unixware/freebird/sound.
Subject D36) Where can I get the GNU debugger (gdb) for UnixWare 2?
This can be found in the developer section of the freebird
archive. Check ftp://ftp.freebird.org/unixware/developer.
Subject: D37) How can I debug an application without the source code?
Peter Lord writes:
If you are a developer working on a new software product, then debugging
an application is fairly straight forward. But what can you do if you
are an end user and don't have access to the source code?
You may come across this problem when trying to run an application
designed for a different operating system on UnixWare.
Truss
Truss(1) is a wonderful program designed for debugging BINARY programs.
It takes control of the process you are interested and prints out all
the system calls your program makes!
For example, if you tried to run the SCO version of Framemaker 3.1X on
UnixWare, you will find it fails without any sensible error message. By
trussing the Framemaker binaries, you can find out if any of the system
calls are failing. In this example, it was easy to find out that
Framemaker was trying to run a program from the bin.i386 directory ...
but only a bin.scounix directory existed. A simple symbolic link brought
the application into life!
Lets take a simple example.
$ ls /fred
UX:ls: ERROR: Cannot access /fred: No such file or directory
$
In this case we get a error message which can be understood ... but this
may not always be the case. Now, if we truss this same command we get :-
$ truss -o/tmp/trussout ls /fred
UX:ls: ERROR: Cannot access /fred: No such file or directory
$
and the file /tmp/trussout contains :-
...
lxstat(2, "/fred", 0x08047520) Err#2 ENOENT
...
write(2, " U X : l s : ", 7) = 7
write(2, " E R R O R", 5) = 5
write(2, " : ", 2) = 2
write(2, " C a n n o t a c c e s".., 47) = 47
_exit(2)
Here you can see that ls has made a system call lxstat which returns an
error.
So you can see that although truss cannot follow all of the program, it
can print out the system calls and so give you some clues to where your
program is failing.
One useful truss option is -t. This allows tracing of certain system
calls only (and thus reducing the amount of output you need to scan
through). See the truss manual page for more options.
Truss can even follow processes which are currently running! For
example, if you want to debug your running lockd daemon, use ps to find
out it's process id and then use the command truss -p pid.
Subject: D38)When I link I can 't find the syslog routines, what should I do?
You need to include libgen. Add -lgen to your link line.
Subject: D39) When I link I can 't find the strcasecmp routine?
You need to link to the ucblib library. This has to be done
as follows:
-lc -L/usr/ucblib -lucb
Alternately just extract the object file (stricmp.o) from
/usr/ucblib/libucb.a and link that to your executable:
$ cd /tmp
$ ar x /usr/ucblib/libucb.a stricmp.o
Subject: D40) When I link I can 't find the alloca routine?
See D38 above.
Subject: D41) How do I make a pkgmk add-on package?
UnixWare supports the SVR4 packaging tools and the pgmk(1) utility
to create a package. If you cannot find the packaging tool that you need ,
check that you have the Software Packaging Tools (softint) package
installed from the SDK (or ask SCO to make a PTF - since they
tools really ought to be available to all developers)
These three tools are in the Base
/usr/bin/pkginfo - display software package information
/usr/bin/pkgparam - display package parameter values
/usr/bin/pkgtrans - translate package format
The key scripts for creating packages are in the SDK softint package:
/usr/bin/pkgmk - create a package
/usr/bin/pkgproto - generate a package prototype file
For further details refer to the Software Tools Book in Dynatext, Chapter 8,
or the UNIX SVR4 Programmer's Guide: System Services
and Application Packaging Tools Manual. The Generic Application Binary
Interface (gABI) specification is also a good reference for this material.
This will allow the system to track all installed software thus
ensuring its integrity.
Its good practice for applications to only install or create files in
designated places within the file tree away from the system
files if possible. A possible scenario is noted below.
root or "/"
/ | \ \
/ | \ \
opt usr etc var
/ | \ | | / \
bin man lib bin opt opt tmp
/ \ / \
pkg1 pkgn pkg1 pkgn
/opt, /var/opt and /etc/opt\f1 are reserved in the file
tree for the installation of application software packages. Each
add-on package should adhere to the following rules.
Static package objects should be installed in /opt/lib/pkg, where
pkg is the package abbreviation.
Package objects that change in normal operations (for example,
log and spool files) should be installed in /var/opt/pkg
Machine-specific configuration files should be installed in
/etc/opt/pkg.
Executables that are directly invoked by users should be installed
in /opt/bin
Only package objects that must reside in specific locations within the
system file tree in order to function properly (for example,
special files in /dev) should be installed in those locations.
An advantage of putting all package files under /opt is that allows
that directory to be networked.
A very simple example - The mush Package
-----------------------------------------
To create an SVR4 package the following files should be created
copyright pkginfo prototype postinstall
copyright
---------
This contains the copyright notice for the package. For example:
Mush is copyright (c) 1986, 1987, 1988, 1989, 1990, 1991 by Dan Heller.
All Rights Reserved. This software is not in the public domain.
Redistribution of the unmodified source code is permitted as long as all
copyright notices remain intact and all other identifying notices remain
in the code and in the binary. This includes message headers on outgoing
mail and the startup message. Future releases may extract the release
version from the message headers of mush-originated messages to aid in
implementing features and providing backwards compatibility with previous
versions. Modification of the source for personal use is permitted.
Modifications sent to the authors are humbly accepted and it is their
prerogative to make the mods official. Only the "official" sources may be
redistributed and no sale of the code or any part thereof is permitted
without written consent from the authors. Further, no part of the code
may be used in any other product, free or otherwise, without consent from
the authors. Distribution of sources containing adaptations of the SunView
interface to XView or to any X11-based interface is expressly prohibited.
MUSH IS PROVIDED AS IS, WITHOUT WARRANTY. AUTHORS HEREBY DISCLAIM
ALL WARRANTIES INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES
OF FITNESS FOR A PARTICULAR PURPOSE.
pkginfo
-------
pkginfo is an ASCII file that describes the characteristics
of the package along with information that helps control the
flow of installation. It is created by the software package
developer.
Each entry in the pkginfo file is a line that establishes
the value of a parameter in the following form:
PARAM="value"
An example follows:
$ cat pkginfo
PKG="mush"
VERSION="7.2.5"
NAME="Mail Users Shell"
CATEGORY="application"
CLASSES="none"
PREDEPEND=mush
VENDOR="(c) 1989 Dan Heller"
For more information see pkginfo(4).
prototype - package information file
--------------------------------------
prototype is an ASCII file used to specify package
information. Each entry in the file describes a single
deliverable object. An object may be a data file,
directory, source file, executable object, etc. This file
is generated by the package developer (most often using the
pkgproto command).
Entries in a prototype file consist of several fields of
information separated by white space. Comment lines begin
with a ``#'' and are ignored.
An example follows:
$ cat prototype
i pkginfo
i copyright
i postinstall
d none /opt ? ? ?
d none /opt/bin ? ? ?
d none /etc ? ? ?
d none /etc/mail ? ? ?
f none /opt/bin/mush 0755 bin bin
d none /opt/lib/mush 0755 bin bin
d none /opt/man 0755 bin bin
d none /opt/man/man1 0755 bin bin
f none /opt/man/man1/mush.1 0644 bin bin
f none /opt/lib/mush/Mushrc 0644 bin bin
f none /opt/lib/mush/cmd_help 0644 bin bin
f none /opt/lib/mush/Mailrc 0644 bin bin
f none /opt/lib/mush/Gnurc 0644 bin bin
f none /opt/lib/mush/advanced.mushrc 0644 bin bin
f none /opt/lib/mush/sample.mushrc 0644 bin bin
For more information see prototype(4).
postinstall - postinstallation commands
-------------------------------------------
This script is run with root privilege after the installation (note
that a preinstall file can be created to run commands before the
installation). (Note that this script asks for input and
strictly speaking that should be done thru a request script).
An example follows:
$ cat postinstall
echo "\n\t NOTE: To setup your From: address line edit /etc/mail/mush/Mushrc"
echo "\tAttempting to set this up. If not setup the From: line will default"
echo "\tto the system name. Its best to use a domain address i.e. site.domain"
echo "\talthough you must be registered."
echo "\tEnter your domain address --->\c"
read address
if [ "${address}" = "" ]
then
echo "\tYou did not enter an address so /etc/mail/mush/Mushrc not setup."
else
echo "\tYou entered \"$address\" as your domain name"
echo "\tThis will now be entered in the /etc/mail/mush/Mushrc file."
echo "\tIf you made a mistake edit the file by hand."
fi
sleep 2
echo "set hostname=\"$address\"" >>/etc/mail/mush/Mushrc
pkgmk - produce an installable package
---------------------------------------
To build the package use pkgmk.
NOTE: pkgmk requires root privilege.
For example to create the package in /var/spool/pkg.
Ensure you are the same directory as the packaging commands,
and that the target package files are installed in the correct
locations (this simplifies things a lot).
# pkgmk -ai386 -r /
If you want to overwrite an existing package in the /var/spool/pkg
directory use the "-o" flag to pkgmk; pkgmk -ai386 -o -r /.
If you don't want to install the utility in its final
destination prior to package creation, then a tree of files
can be created in a subdirectory call root, and the prototype
file edited as follows:
$ cat prototype
i pkginfo
i copyright
i postinstall
d none /opt ? ? ?
d none /opt/bin ? ? ?
d none /etc ? ? ?
d none /etc/mail ? ? ?
f none /opt/bin/mush=root/opt/bin 0755 bin bin
d none /opt/lib/mush=root/opt/lib 0755 bin bin
d none /opt/man=root/opt/man 0755 bin bin
d none /opt/man/man1=root/opt/man/man1 0755 bin bin
f none /opt/man/man1/mush.1=root/opt/man/man1/mush.1 0644 bin bin
f none /opt/lib/mush/Mushrc=root/opt/lib/mush/Mushrc 0644 bin bin
f none /opt/lib/mush/cmd_help=root/opt/lib/mush/cmd_help 0644 bin bin
f none /opt/lib/mush/Mailrc=root/opt/lib/mush/Mailrc 0644 bin bin
f none /opt/lib/mush/Gnurc=root/opt/lib/mush/Gnurc 0644 bin bin
f none /opt/lib/mush/advanced.mushrc=root/opt/lib/mush/advanced.mushrc \
0644 bin bin
f none /opt/lib/mush/sample.mushrc=root/opt/lib/mush/sample.mushrc \
0644 bin bin
Package creation is the simply:
pkgmk -ai386 -o
(no -r / this time)
Creating a floppy copy
----------------------
To create a floppy copy:
# pkgtrans spool diskette1 mush
Another Example - Sendmail
============================
This example uses the menu routines to generate a blue screen menu
upon installation.
The packaging tree is listed below:
$ find . -print
.
./install
./install/copyright
./install/i.save
./install/menu.1
./install/menu.err
./install/menu.intro
./install/postinstall
./install/postremove
./install/preinstall
./install/r.save
./install/request
./pkginfo
./prototype
./root
./root/etc
./root/etc/mail
./root/etc/mail/mailsurr
./root/usr
./root/usr/ucblib
./root/usr/ucblib/sendmail
./root/usr/ucblib/sendmail.cf
$
The contents of some of the key files above are listed below:
copyright
---------
copyright - the copyright notice
i.save
------
i.save - a script run by the system to backup files
#!/bin/sh
# i.save script
# script which backs up files
#
while read src dst ; do
[ "$src" = /dev/null ] && continue
if [ -f $dst ] ; then
echo $dst | cpio -pdmu $PKGSAV >/dev/null 2>&1
fi
cp $src $dst.tmp || exit 1
mv $dst.tmp $dst || exit 1
done
exit 0
# end of i.save script
menu.1
--------
menu.1 - part of the blue screen menu
.pageno
Page %d of %d
.ul
Sendmail Installation
.helpbanner
Help on Sendmail Installation
.hhelp_ban
Help on menus
.ur
Introduction
.ll
Please make a selection.
.lr
Del=Cancel F1=Help
.top
This is a binary distribution of Sendmail 8.7.3 for UnixWare 2.x.
This package sets up your system to use Sendmail instead of the
default mailsurr based mailer.
AS SUCH, THIS IS AN UNSUPPORTED PACKAGE, TO BE USED AT YOUR OWN RISK.
This package saves all files it changes so they can be restored
on its removal. You must restart TCP/IP after installing this package
sh /etc/inet/rc.restart
This port by :
Joe Doupnik, jrd@cc.usu.edu, Utah State University, 31 Dec 1995.
.bottom
press 'ENTER' (or 'RETURN') to install.
.help
The following assumptions are made about the installation:
o The directories used by this pacakage are
/usr/ucblib - for the mail executable
/etc/mail - for the mail configuration
.helpinst
Esc=Quit Help Del=Cancel F1=Instructions
.hhelpinst
Esc=Quit Instructions Del=Cancel
menu.err
----------
menu.err - another part of the blue menu screens
.pageno
Page %d of %d
.ul
Sendmail Installation
.helpbanner
Help on Sendmail Installation
.hhelp_ban
Help on menus
.ur
Error
.ll
Press return when ready
.lr
Del=Cancel F1=Help
.top
`echo $ERROR`
.bottom
Press 'ENTER' (or 'RETURN') to continue.
.help
.helpinst
Esc=Quit Help Del=Cancel F1=Instructions
.hhelpinst
Esc=Quit Instructions Del=Cancel
menu.intro
-----------
menu.intro - more of the blue menu
.pageno
Page %d of %d
.ul
Sendmail Installation
.helpbanner
Sendmail Copyright Notice
.hhelp_ban
Help on menus
.ur
Introduction
.lr
Del=Cancel F1=View Copyright
.ll
Press RETURN when ready
.top
Welcome to the Sendmail installation.
This installs sendmail as the default mailer.
This package is copyrighted. To re-view the copyright notice press F1 or '?'.
.bottom
Press 'ENTER' (or 'RETURN') to continue.
.help
The full notice may be found in /var/sadm/pkg/sendmail/install/copyright
Copyright (c) 1983, 1995 Eric P. Allman
Copyright (c) 1988, 1993
The Regents of the University of California. All rights reserved.
.helpinst
Esc=Quit Copyright Del=Cancel F1=Instructions
.hhelpinst
Esc=Quit Instructions Del=Cancel
postinstall
-----------
postinstall - the script executed after the software is installed
#!/bin/sh
# postinstall script
if [ -f /etc/inet/config ] ; then
if grep sendmail: /etc/inet/config >/dev/null ; then
:
else
# Save old version with the packaging
echo /etc/inet/config | cpio -pdmu $PKGSAV 2>/dev/null
echo '8:/usr/ucblib/sendmail::y:/usr/ucblib/sendmail.cf:-bd -q2h :' \
>> /etc/inet/config
fi
fi
echo /etc/init.d/smtpinit |cpio -pdmu $PKGSAV 2>/dev/null
TMP=/tmp/pkg$$
echo "#!/bin/sh \nexit 0" > $TMP
cat /etc/init.d/smtpinit >>$TMP
cp $TMP /etc/init.d/smtpinit
exit 0
# end of postinstall script
postremove
-----------
postremove - script executed to removing the software
#!/bin/sh
# postremove used to restore original files
cd $PKGSAV
echo "Warning the following files have been restored, any changes"
echo "made to them since installing this package will be lost."
find . -type f -print|cpio -pdmuv /
exit 0
# end of postremove
preinstall
----------
preinstall - executed before installing files
#!/bin/sh
# preinstall - some dependency checks
rel=`uname -v |cut -f1 -d"."`
if [ "$rel" -ne "2" ]
then
echo "This package requires UnixWare version 2.x to install."
exit 1
fi
sh /etc/rc2.d/S81smtp stop
exit 0
# end of preinstall
r.save
-------
r.save - class script to restore files
#!/bin/sh
#
# script which backs up files
#
cd $PKGSAV
while read file ; do
if [ -f ./$file ]
then
mv ./$file $file.tmp || continue
mv $file.tmp $file
else
rm -f $file
fi
done
exit 0
# end of r.save script
request
-------
request - script to display the menus & handle the input
# geta question default
MENU=/usr/sbin/menu
cd $REQDIR || exit 1
rm -f /tmp/out.$$
$MENU -f menu.intro -o /tmp/out.$$
if [ ! -f /tmp/out.$$ ] ; then
exit 1
else
. /tmp/out.$$
fi
rm -f /tmp/out.$$
$MENU -f menu.1 -o /tmp/out.$$
if [ ! -f /tmp/out.$$ ] ; then
exit 1
else
. /tmp/out.$$
fi
echo "NPATH=$NPATH" >> $1
pkginfo
-------
The pkginfo script has the save class defined so
that files can be backed up and restored using the
i.save and r.save scripts
ARCH=i386
PKG=sendmail
VERSION=8.7.3
NAME=Sendmail Mailer
CATEGORY=system
DEPEND=sendmail
CLASSES=none save
prototype
--------
The prototype shows the save class being used for the
mailsurr, and old sendmail files.
i pkginfo
i preinstall=install/preinstall
i copyright=install/copyright
i menu.intro=install/menu.intro
i menu.1=install/menu.1
i menu.err=install/menu.err
i postinstall=install/postinstall
i postremove=install/postremove
i request=install/request
i i.save=install/i.save
i r.save=install/r.save
d none / ? ? ?
d none /usr ? ? ?
d none /etc ? ? ?
d none /etc/mail ? ? ?
d none /etc/ucbmail ? ? ?
d none /usr/ucblib ? ? ?
f save /etc/mail/mailsurr=root/etc/mail/mailsurr 444 root mail
f save /usr/ucblib/sendmail=root/usr/ucblib/sendmail 04111 root mail
f save /etc/ucbmail/sendmail.cf=root/usr/ucblib/sendmail.cf 444 bin bin
Creating the package
--------------------
In this case
pkgmk -ai386 -o
Subject: D42) How to build binaries on UnixWare to run on other SVR4 systems
such as Solaris x86?
Scott Raney <raney@metacard.com> writes:
1) Always link libraries dynamically.
2) We had to put the following hack in to make UnixWare 2.0 binaries
run on Solaris 2.4:
#ifdef UNIXWARE
extern "C" {
int sys_nerr;
int *__thr_errno()
{
return &errno;
}
}
#endif
3) Be sure to thoroughly test all code that runs subrocesses,
especially code that reads and writes to pipes to the child processes.
The gotchas here are too obscure to detail here, but they'll get you
if you don't hunt them down.
John Moyer (jrm@questconsult.com) writes :
To build binaries that run under Dell Unix from Unixware 2.0x, static
linking is best. Static linking is not possible with Athena Widgets or
wide character support or anything else that requires -lnsl.
To build X11R6 binaries from UnixWare 2.0x to run under Unixware 1.1.4
I found it necessary to link with libc.so and libnsl.so from unixware
1.1.4. This is not necessary if libXaw.so is built with the x.org
wide character support instead of using -lw.
Binaries with "long double" variables do not seem to run under the
Linux iBCS emulation. Static linking seems to me to be best for Linux
iBCS.
Subject: D43)How do I display files open to UnixWare processes?
Vic Abell writes:
A. Lsof (for list open files) will list the files open to UnixWare
2.x processes, including local and remote Internet addresses
for socket files with open connections. Lsof provides a wide
range of filters for selecting the processes to be displayed.
It has an output mode that is designed for easy post-filtering
of output with AWK, PERL, or shell scripts.
Lsof may be found at:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof
A UnixWare 2.x binary may be found at:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/binaries/unixware
but the author (Vic Abell ) recommends you
build your own binary.
Acknowledgements
---------------
Special thanks to Darren R. Davis and the Novell UnixWare
Developer Support team for getting this FAQ going and to
those folks who've made suggestions and contributions either
directly or via the netnews.
----
Andrew Josey.
Disclaimer: Any views expressed are not those of my employer, either past,
present or future.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |