Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!newsfeed.berkeley.edu!ucberkeley!news.svpal.org!xmission!nnrp.xmission!not-for-mail

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!newsfeed.berkeley.edu!ucberkeley!news.svpal.org!xmission!nnrp.xmission!not-for-mail
From: [email protected] (Boyd Lynn Gerber)
Newsgroups: comp.unix.sco.programmer,comp.answers,news.answers
Subject: Quarterly ASCII posting of SCO Programmer's FAQ
Supersedes: <[email protected]>
Followup-To: comp.unix.sco.programmer
Date: Thu, 11 Feb 2010 00:05:34 -0700 (MST)
Organization: ZENEZ
Lines: 2916
Sender: [email protected]
Approved: [email protected]
Expires: 26 May 2010 07:05:01 GMT
Message-ID: <[email protected]>
NNTP-Posting-Host: suse104.zenez.com
X-Trace: news.xmission.com 1265871944 11455 198.60.105.164 (11 Feb 2010 07:05:44 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 11 Feb 2010 07:05:44 +0000 (UTC)
Summary: This posting gives an ASCII dump of the entire SCO Programmer's
FAQ for newsgroups quarterly.
X-Disclaimer: Approval for *.answers is based on form, not content.
Xref: senator-bedfellow.mit.edu comp.unix.sco.programmer:18034 comp.answers:66911 news.answers:325404

Archive-name: sco/programmers-faq
Posting-Frequency: quarterly
Version: 1.0.3a
Last-modified: 2007/11/26
URL: http://www.zenez.com/cgi-bin/scoprogfaq/faq
Copyright: (c) 1999-Present SCO Programmer's FAQ
Maintainer: Boyd Lynn Gerber <[email protected]>
Disclaimer: Approval for *.answers is based on form, not content.

comp.unix.sco.programmer "SCO Programmer's FAQ" is best viewed in html
because of its format. Please visit our website at

http://www.zenez.com/cgi-bin/scoprogfaq/faq

SCO Programmer's FAQ ASCII.

THE_URL:http://www.zenez.com/cgi-bin/scoprogfaq/faq?_recurse=1
THE_TITLE:SCO comp.unix.sco.programmer FAQ.
(Category) SCO comp.unix.sco.programmer FAQ.
This services tries to provide answers to the Frequently Asked
Questions in news:comp.unix.sco.programmer.
A backup of the most important files are on.
ftp://ftp.lerctr.org/pub/zenez/
Thanks to Larry Rosenman [email protected]

Since it is based on traffic in that group, it has a definite slant
toward the SCO (Caldera) UNIX/OpenDesktop/OpenServer product families.
However coverage is given to the UnixWare 7(OpenUNIX 8)/OpenServer 6
and OpenServer Development Kit (UDK) as well.

It doesn't try to cover the same ground as the existing FAQs such as
The comp.sco.misc FAQ
http://aplawrence.com/SCOFAQ/
The comp.unix.programmer FAQ
http://www.erlenstar.demon.co.uk/unix/faq_toc.html.
Csh Programming Considered Harmful
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
Raw IP Networking FAQ
http://www.whitefang.com/rin/
The UnixWare 7/OpenUNIX 8/OpenServer 6 FAQ.
http://www.zenez.com/cgi-bin/ou8faq/faq

The UnixWare FAQ
http://www.freebird.org/faq/
The UnixWare 1.x and 2.0 Programmer FAQ
http://www.freebird.org/faq/developer.html
Caldera Support Knowledge Base
http://support.caldera.com/caldera

or many of the other great FAQs available at
http://www.faqs.org

It is strongly encouraged that the answers in here address Caldera
(SCO) UNIX -specific issues.

It is run from the Faq-O-Matic accessable at
http://www.zenez.com/cgi-bin/scoprogfaq/faq
, which means you can create your own entries and amplify or correct
and answers that are here.

Notes to contributors:
You will need to go to the appearance link at the bottom and click on
it. You then select show and show all and then accept. This will allow
you to see the options available. You choose the option you want and
a new screen will come up asking for your email address and password.
You must have an authenticated email address and password. If you have
one just enter it and continue. If you do not will need to be added,
a email address and password is required to add or make changes to this
FAQ. Please help us maintain this FAQ as it is for the entire group.
When entering "natural text" where you still want some control over the
formatting (as this section) note that blank lines must really be blank
(not tabs, not spaces) to start a new paragraph.

Subcategories:
(Category) SCO Development Environments.
(Category) Hardware related programming
(Category) Known bugs in SCO Programming Environments.
(Category) Third-party Languages and Development Tools for SCO
Platforms
(Category) Misc for OpenServer 5.0.X and Unixware 7.x.x / OpenUNIX
8.x.x
(Category) How to Find FAQ
[New Answer in "SCO comp.unix.sco.programmer FAQ."]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. :
SCO Development Environments.
Insert useful description here. What's in this group? Why does it
exist? What doesn't belong here?

Right now, this group tends to be sort of a "catch-all".

It is important to remember that robertl or gerberb are not the FAQ
maintainer. YOU are the FAQ maintainer. If you're tired of answering a
question or seeing it answered in news:comp.unix.sco.programmer it is
your duty as a good net.citizen to plonk the answer into this FAQ.

As you find useful information for programming on SCO OS's, Please add
it to this FAQ. THANKS!
[email protected], [email protected]
Answers in this category:
(Answer) I have a 3.2v4.2 (or earlier) based system. I don't have a
compiler. What are my options?
(Answer) I have a 3.2v4 OS and the SCO 3.2v4 DS. I'm trying to build
something and seem to be missing headers and libraries.
(Answer) I have an OpenServer based system. I don't have a compiler.
What are my options?
(Answer) I tried to build GCC on OpenServer 5 and it burst into
flames.
(Answer) Issues with GDB on OpenServer and UnixWare.
(Answer) How can I build XENIX or DOS binaries on my OpenServer
system?
(Answer) Can I generate binaries that run on older sysem on
OpenServer?
(Answer) Will ELF binaries compiled on OpenServer run on anything
else?
(Answer) Link errors on functions like gethostbyaddr, gethostbyname
(Answer) How do I read or traverse directories within a program?
(Answer) How can I detect null references in my program?
(Answer) Where is alloca()?
(Answer) Purify or other malloc checkers.
(Answer) How can I read kernel data through /dev/kmem in a user
program?
(Answer) How to detect SCO product or version at compile time?
(Answer) How to write dialers
(Answer) POSIX Timers
(Answer) How do I play nice with UUCP locking?
(Answer) SCO CC and foo.cc
(Answer) Which C compiler delivers the best performance?
(Answer) POSIX threads or threads for Unixware and/or OpenServer 5.0.X
and ODT 3.0?
(Answer) Where to get STL for SCO C++?
(Answer) Software packaging and distribution options for OpenServer &
earlier releases
(Answer) Issues if you develop on 5.0.4 and run on earlier OpenServer
(Answer) Issues when compiling on OpenServer, executing on 3.2v4 or
earlier
(Answer) C++: Using STL in a library and I get link errors from it -
Now what?
(Answer) C++: I'm building C++ source with the UDK and I get warnings
about 'omission of explicit type is nonstandard ("int" assumed)'
(Answer) Where to get ANSI/ISO C++ standard library for SCO?
(Answer) My existing C++ code doesn't compile under UDK C++!
(Answer) Recommended books on UNIX internals
(Category) Using FSU Pthreads on SCO systems
(Answer) OLD GDS (as on Skunkware) vs. New GCC 2.95.X or GCC 3.0.X
(Answer) Building Shared libraries with GCC or SCO cc
(Answer) Will UnixWare 2.1 or 7.0 run ibcs/OpenServer binaries?
(Answer) Building GCC 2.8.0 on OpenServer results in alloca link
failure early during the build.
(Answer) I installed GDS or GCC binary kit and nothing works.
(Answer) When I run gcc on osr5 I get "cc: installation problem,
cannot exec `cpp': No such file or directory"
(Answer) Building Perl5.005_03
(Answer) Build DBI with gcc after building perl5.005_03 with SCO cc
(Answer) What's the UDK link order for building Motif programs?
(Answer) Is UDK C++ thread safe?
(Answer) On osr5 when I dlopen a shared library I get "symbol
unresolved" errors
(Answer) Often used or need Flags when using compilers
(Answer) I am having trouble building and running an application with
gcc, but someone else is not.
(Answer) Assembler overview; differences of "AT&T" vs. "Intel" syntax
(Answer) What popular compilers are available?
(Answer) Gnu pthreads pth-1.2.2 passes all tests on OSR 5.0.5
(Answer) How do I get BerkeleyDB.3.1 to compile on OpenServer 5.0.X
and UnixWare 7.X.X?
(Answer) OpenServer 5.0.X, Error as or ld illegal option --b or as: TO
FIX: Usage: [-Qyn] [-VTRmn] [-Ydm,dir] [-o outfile] [-t target] file.
What is wrong?
(Answer) What patches are needed for OpenSSL 0.9.6b for UnixWare or
OpenUNIX 8?
(Answer) How do I fix Msql-Mysql-modules-1.2216 problem with
__deregister_frame_info?
(Answer) What is need to compile MySQL on SCO Operating Systems (OS)
OpenServer and UnixWare 7.X.x?
(Answer) Resources on the SCO web site.
(Answer) How do I determine which development System is best for me to
use?
(Answer) How do I determine what dynamic libraries an application
depends upon?
(Answer) How do I do Java programming?
(Answer) How do I do Java native code (JNI) programming?
(Answer) Why are there two threads APIs on UnixWare? Which should I
use?
(Answer) How do I do XML programming?
(Answer) How do I do Web Services (SOAP) programming?
(Answer) What J2EE implementations or Java app servers are available?
(Answer) About C language and Oracle C API
[New Answer in "SCO Development Environments."]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
I have a 3.2v4.2 (or earlier) based system. I don't have a compiler.
What are my options?
If you really want to be able to compile anything, buy the SCO
Development system. That version (and earlier) of SCO UNIX did not
come with the needed libraries or headers to allow use of third party
compilers. While some people on the net have put together packages to
allow you to compile minimal programs, there are still lots of
problems in the area of networking and X that remain unresolved.
Before you buy the compilers for this old version of the OS, you
should probably consider the upgrade to OpenServer.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
I have a 3.2v4 OS and the SCO 3.2v4 DS. I'm trying to build something
and seem to be missing headers and libraries.
In that version of the OS, the TCP/IP and NFS development systems were
not included in the DS, but were bundled as separate packages. You
have to either get the "TCP/IP Development Kit" and the "NFS
Develoment" kit or consider the upgrade paths mentioned above. These
will give you, for example, libsocket.
[email protected]
There were always bundled DS's (ODT DS) corresponding to the
same-time-release Unix, TCP, NFS, etc. DS's. Unfortunately, packaging
was such that if you had standalone Unix + TCP, you needed standalone
Unix DS, TCP DS. Couldn't use Unix + ODT DS, nor ODT + Unix DS (though
the latter might actually have worked, I forget). So if you're trying
to buy a DS now, you need to be aware of the many opportunities to buy
the wrong thing.
From Bela Lubkin, minor editing by robertl
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
I have an OpenServer based system. I don't have a compiler. What are
my options?
If you're using Free OpenServer and comply with the licensing
requirements, install the Free OpenServer compiler from the same CD.
You cannot install the Free OpenServer compiler on a commercially
licensed OpenServer.

SCO's OpenServer Development system is available as a commercially
supported product and includes two compilers, debuggers, and tools
such as the custom distribution mastering toolkit. For more
information, see http://www.sco.com/developer/products.htm. The SCO
part number for SCO OpenServer Development System (media and license)
is SA105-UX74-5.0.

OpenServer includes all the necessary libraries, headers, man pages,
and the linker to allow the user of third party develoment systems.
One such system is the GNU Development System that's available on the
Skunkware CD or the newer version available on Robert Lipe's home page
and mirrored on SCO's Web site. This kit includes make, the
assemblers, the debuggers, and everything you need for a functional
development environment.
This kit is available at ftp://ftp.zenez.com/pub/zenez/gcc and has
documentation at ftp://ftp.zenez.com/pub/zenez/gcc/sco_ds.html and a
little FAQ of its own (that should ultimately be smooshed into this
one) at ftp://ftp.zenez.com/pub/zenez/gcc/gds_faq.html .
[email protected]
See also http://www.sco.com/developers/products/devkits.html.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
I tried to build GCC on OpenServer 5 and it burst into flames.
It is time to start using newer version of gcc. Take a look at
ftp://ftp2.caldera.com/pub/
This is left for historical purposes.
The first FSF release of GCC to include the necessary support to host
or target OpenServer was 2.8.0. EGCS has supported OpenServer 5 since
the epoch. Anything before this requires a patched version of GCC.
Robert Lipe did the port of the GNU tools that appears on the
Skunkware '96 CD and on ftp://ftp2.caldera.com/pub/Skunk96 or the old
site ftp://ftp.sco.com . It is not a simple matter of 'configure ;
make install'. It's a complicated product to build and unless you're
planning to slog around in compiler internals, you really want to use
the available binary kits.
It is time that you start using a newer gcc. Please see
ftp://ftp2.caldera.com/pub/skunkware . This is also mirrored on
ftp://ftp.sco.com/skunkware . It is required that you install the
necessary libraries and headers as described in the documention for
that package that is in the "sco_ds.html" file at those URLs.

The major contributors of the OpenServer code in GCC (Kean Johnston
and Robert Lipe) are active members of the EGCS development team. EGCS
is an enhanced GNU compiler system. EGCS contains complete support for
OpenServer 5 in both COFF and ELF modes and has received much
attention and testing. See http://gcc.gnu.org for more details.

GCC does include support for 3.2v4.2 and earlier SCO releases, though
it requires the SCO development system be installed.
EGCS also includes support for UnixWare 7 and for UDK.
[email protected], [email protected]
GCC 2.8.0, released in 01/98, almost has functioning support for the
OpenServer family of products. There is another entry in this FAQ that
contains the necessary directions to circumvent the problem.
[email protected]
In recent years, GCC 2.95.3 has packaged and supported for OSR5 (and
UW7 as well). No GCC 3.x is as of yet provided by SCO.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Issues with GDB on OpenServer and UnixWare.
OpenServer 5 support in GDB was sneaked into GDB 4.16 at the last
minute and suffered from some problems. You must run

configure --target=i486-unknown-sco3.2v5.0.0elf'

to get a gdb that recognizes both COFF and ELF.

Generally, you'll be better off using a GDB from Skunkware or building
a newer version. 4.17 and 4.18 seem to work well.
[email protected]
GDB 4.17 works well on OpenServer.
[email protected]
GDB 4.18 seems to work OK for OpenServer. For UnixWare 7, you must
either configure --target=i686-UnixWare7-sysv42mp or apply a minor
patch to configure.tgt.
[email protected]
If you are using gdb (or the native debugger) on Openserver and you
get warnings of the form "no debugging symbols" on an ELF executable
even though you are sure you gave specified -g on the object and
executable build lines make sure that *all* the objects ( and
libraries) going into the executable are also ELF format.
The devsys will make ELF executables if any of the incoming objects
are ELF. Any COFF files are converted to ELF format in passing but in
the process symbol and debug information is removed from the resulting
executable.
All COFF objects -> COFF executable with symbol info All ELF objects
-> ELF executable with symbol info Mixed ELF/COFF objects -> ELF
executable - symbol info stripped.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How can I build XENIX or DOS binaries on my OpenServer system?
By purchasing the "Xenix/DOS Cross Development Supplement". The SCO
part number for the media and license is SA575-UX72-5.0.
This gives you the Microsoft based tools that comprised the earlier
development systems repackaged to work on OpenServer.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Can I generate binaries that run on older sysem on OpenServer?
Yes, if you constrain yourself to use only features that existed in
the older versions. For example, you can't use mmap(S) (A feature new
in OpenServer) and expect it to work on older versions. You should
also read the man page for cc(CP) for related issues.

There are some bugs in the handling of POSIX terminal handling that
affect this ability. #FIXME# more details.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Will ELF binaries compiled on OpenServer run on anything else?
If compiled with the "UnixWare/OpenServer Development Kit" (UDK),
binaries can run on any current SCO operating system. These tools can
be hosted on OpenServer, UnixWare 2, or UnixWare 7. Binaries compiled
with those tools that use no non-conforming facilities can run on any
of these systems.
Linux and the BSD familes can run many OpenServer and UnixWare
binaries via their ibcs2 support.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Link errors on functions like gethostbyaddr, gethostbyname
For the unresolved functions, do a 'man functionname'. For example, a
'man gethostbyaddr' shows
gethostbyname(SLIB)
*******************

____________________________________________________________________________
gethostbyname, gethostbyaddr, sethostent, endhostent, herror, hstrerror --
get network host entry

gethostbyname- get network host entry by name

gethostbyaddr- get network host entry by address

[ ... ]
Syntax
======

cc . . . -lsocket

#include <netdb.h>

This man page tells us that we must #include <netdb.h> before using
these functions and that we must be sure that our cc line links
against the socket library by having a '-lsocket' at the end.

This same technique should be applied to any link error that you feel
the system really does know about but you just don't know where it is.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How do I read or traverse directories within a program?
ftw(S) will traverse and recurse a path, calling a function of your
creation on each object found.

If you just want to open a directory and read it, you must use the
functions described in directory(S) such as opendir(S) and readdir(S).
In OpenServer, you can no longer read directories like a file.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How can I detect null references in my program?
On OpenServer, there are two kernel global variables of interest in
/etc/conf/pack.d/kernel/space.c that may be set.

If notice_null_refs is non-zero, a kernel message will be generated
when a program attempts to reference the page with a virtual address
of zero.

If signal_null_refs is non-zero, the kernel will detect zero page
references and deliver a signal to the process, killing it and likely
leaving a core dump for analysis.

TLS594, available at ftp://ftp.sco.com/TLS allows finer control of
these actions.

[email protected]
On UnixWare 7, the 'nullptr' command can enable, disable, or trap null
pointer references on a per-uid basis. On UW7 before 7.1.0, many
system utilities (vi, more, pg) become unstable if nullptr disable is
ineffect.
[email protected]
With UW7.1, the MALLOC_CHECKS environment variable can be set to cause
page zero to be unreadable. See malloc(3C). This works on a
per-process basis. Note that since page zero must first be read to
turn off access, when "nullptr disable" has been set, this
MALLOC_CHECKS setting will cause a process to die when it first gets
into malloc() code.
[email protected]
Beginning with UnixWare 7.1.3 see also memtool(1) for dealing with
null pointers and related memory bug checks.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Where is alloca()?
Add -lPW to your link line to get alloca()
[email protected]
Note that for UDK C++, alloca() is not supported.

(This is because it is incompatible with an efficient exception
handling implementation. Note that better alternatives to alloca()
exist in C++, such as the vector class in the draft standard library
or the Block class in UDK Standard Components.)
[email protected]
If you really need an alloca() to build something and are willing to
live with the above and can't find one anywhere else
many of the gnu software sources include one.

bash-1.14.6/lib/malloc/alloca.c
bash-1.14.6/lib/malloclib/alloca.c
bash-2.0/lib/malloc/alloca.c
diff-2.6/alloca.c
diffutils-2.7/alloca.c
fileutils-3.16/lib/alloca.o
find-3.6/lib/alloca.c
findutils-4.1/lib/alloca.c
gawk/gawk-3.0.3/alloca.c
make-3.75/alloca
readline/alloca.c
sed-2.05/alloca.c
tar-1.12/lib/alloca.c

[email protected]
Heres an asm version (from lxrun)
alloca.s
.text
.globl alloca
.align 4
alloca:
popl %edx / return address
popl %eax / nbytes
movl %esp,%ecx
subl %eax,%esp / calculate new esp
andl $-4,%esp / make sure stack is 4 byte aligned
movl %esp,%eax / return pointer to new memory in eax
pushl 8(%ecx) / copy saved registers
pushl 4(%ecx)
pushl 0(%ecx)
pushl %ecx / we need to push a fake argument here
/ since alloca's caller will attempt to
/ clean up the stack

jmp *%edx / return

It'll build on Osr5 and UW7 with a simple Makefile rule referring to
alloca.o

[email protected]
In the UDK and in UW7, there is an intrinsic version of alloca() built
into the compiler. It is enabled via -Kalloca.
[email protected]
The UDK C++ compiler does now support -Kalloca as well. I think this
change was made as of UW 7.1.0 or thereabouts.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Purify or other malloc checkers.
On Jan 19, 1996, Larry Phelps said:

I know of two such products for SCO Unix these:

Insure++:
Parasoft Corporation
2031 South Myrtle Avenue
Monrovia, CA 91016
Phone: (818) 305-0041
Fax: (818) 305-9048
Email: [email protected]
HTTP: http://www.parasoft.com

Sentinel:
AIB Software Corporation
1145 Herndon Parkway
Herndon, Virginia 22070
Phone: (703) 787-7700
Fax: (703) 787-7720
Email: [email protected]
HTTP: http://www.aib.com

[email protected]
checkergcc exists for linux. Could probably be ported to SCO systems.
[email protected]
For C++, the UnixWare 2.x and UDK Standard Components has a memory
checking tool called 'fs'. It's not as powerful or transparent as
commercial tools such as Purify, but it's better than nothing.

[email protected]
On UnixWare 7 and on UDK, the standard malloc library has
instrumentation that can be turned on at runtime. If you export
MALLOC_CHECKS, you can control the tests that are performed on the
heap.
UnixWare 7.1.0 has even more instrumentation and can deliver a SIGSEGV
(conveniently trapping you into a debugger) at the bus cycle that
delivers the bounds exception.
[email protected]
Electric Fence from Bruce Parens works just fine on OpenServer. I
don't really know that it offers anything above the MALLOC_CHECKS
tests in the system libraries.
[email protected]
dmalloc (www.dmalloc.com) works fine with OSR5.
[email protected]
Beginning with UnixWare 7.1.3 there is the "memtool" tool, which does
a lot of the memory error detection work that commercial tools like
Purify do. See http://uw713doc.sco.com/en/man/html.1/memtool.1.html or
the memtool(1) man page on your system.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How can I read kernel data through /dev/kmem in a user program?
This can be a powerful technique, but it is also horribly
non-portable. Kernel data structures can and do change between
releases, so your program may break.

The basic idea is to call nlist(S) with the table of kernel symbols
you wish to examine. nlist will then fill in the addresses of those
symbols. You can then open /dev/kmem, use the addresses to lseek(),
then issue a read(). On systems that have mmap() available, this is a
good use for it.

You can look at the sources of programs like u386mon for examples of
how to do this.
An OpenServer-specific extension is the tab(HW) driver. See that man
page and string(HW), and look in /dev/table and /dev/string to see how
it works. This only works for a small fixed subset of kernel data.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How to detect SCO product or version at compile time?
Ordinarily, this is a bad idea. Rather than basing your code on "am I
on OpenServer or not?", you're typically more interested in, say, "do
I have mmap(S) or not?" Programs like GNU autoconf provide a powerful
way to test for features.

The SCO provided compilers and the GCC's that are truly
OpenServer-aware all provide a manifest "_SCO_DS" that is set to one
when targeting SCO OpenServer.

[email protected]
That having been said heres some code that attempts to detect the various SCO
platforms upto and including Gemini - It will probably report UDK on
Osr5 and UW as Gemini I.

#include <stdio.h>

main()
{
#if defined(_SCO_DS)
printf("OpenServer\n");
#elif defined(__UNIXWARE__)
printf("UnixWare gcc\n");
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
printf("Gemini I cc\n");
#else
printf("UnixWare cc\n");
#endif
#elif defined(M_UNIX)
printf("ODT 3 or earlier\n");
#else
printf("Other platform\n");
#endif
}

[email protected]
Heres a slight update that understands UW7 CC

#include <stdio.h>

main()
{
#if defined(_SCO_DS)
printf("OpenServer\n");
#elif defined(__UNIXWARE__)
printf("UnixWare gcc\n");
#elif defined(__USLC__)
# if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
printf("Gemini I cc (UW7 and UDK)\n");
# else
# if defined(__SCO_VERSION__)
printf("Gemini I CC (UW7 and UDK)\n");
# else
printf("UnixWare cc\n");
# endif /* SCO_VERSION */
# endif /* STDC_VERSION */
#elif defined(M_UNIX)
printf("ODT 3 or earlier\n");
#else
printf("Other platform\n");
#endif

/* uw7 ccs */
#if defined(__SCO_VERSION__)
printf("__SCO_VERSION__ is %ld\n", __SCO_VERSION__);
#endif

}

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How to write dialers
look at ecu, XC
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
POSIX Timers
mkdev suds.

They are buggy. Many TAs available on this subject.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How do I play nice with UUCP locking?
/usr/spool/uucp/LCK.ttyxx, suid uucp, look at xc, ecu, others. Include
url.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
SCO CC and foo.cc
Some earlier SCO C++ compilers do not accept some commonly used C++ source
file suffixes, such as .cc. In this case the solution is to give the option

CC +.cc ...

Note that more recent OpenServer CC commands do accept .cc and other common
suffixes, as do the UnixWare 2.x and UDK CC commands.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Which C compiler delivers the best performance?
There are at least four popular compilers on SCO OpenServer and two
for UnixWare.

1) /bin/cc is based on the USL cc, not the Microsoft cc that shipped
with earlier SCO products. This is actually a respectable compiler. It
generates very good code, has a reliable optimizer, and is pretty
quick and solid. You can control optimizations with the -O flags and
can fine tune the optimizations with the -K options.

2) icc ships with the SCO DS and is based on the Intel Reference
Compiler. This compiler can generate amazing code and very good
warnings and diagnostics about your source. It can generate Pentium
Pro specific optimizations. The price you pay for all this
optimization is high in terms of compile time. It can be slow to build
your program.

3) gcc is part of the GNU ds. It generates code that is comparable to
the quality of the /bin/cc output. The warnings and diagnostics are
good. Optimizations can be controlled via the -O, -m, and -f flags.

4) UDK compiler. See the below for more information on the
developement kits available for SCO OS's.

http://www.sco.com/developers/products/devkits.html

All three compilers are ANSI C by default, with options to fall back
to K&R.

If you're looking for a "magic bullet" from the compiler to speed up
your program by an order of magnitude, just by using a different one
or by wiggling some compiler switches, don't. Only after you've highly
tuned your algorithms and implementation should you even worry about
compiler performance. Even then, you should be prepared to stare at
the compiler output and run extensive tests before making an informed
decision.

[email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
POSIX threads or threads for Unixware and/or OpenServer 5.0.X and ODT
3.0?
Unixware has UI (UNIX International) threads. UnixWare 7.0.1 and
higher support POSIX (P1003.1c) threads.

OpenServer 5.0.X has DCE threads which can be purchased in the US at
800-SCO-UNIX or any authorized SCO UNIX reseller/dealer. This is very
expensive.

There are two possible GPL treads options available. Both were
orginally submitted by ARTURO MONTES <[email protected]>
Thanks!! There is a pthreads package on Skunkware 97. Custom
installable media images for the OpenServer pthreads Skunkware package
are at :

http://www.sco.com/skunkware/osr5/libraries/pthreads/VOLS.tar

This is proven's 1.60 Beta 5 Posix threads implementation ported to
SCO OpenSever 5.0.X!

The second is FSU threads.

http://moss.csc.ncsu.edu/~mueller/pthreads/

A modified to work with OpenServer is available at

ftp://www.zenez.com/pub/zenez/prgms/threads.tar.gz

You need to use GDS in Skunkware 95 (95q4c). This is necessary because
GNU gcc 2.7.2 in Skunkware 97 hasn't GNU as.
Currently there is an alpha version of mysql working with FSU threads.
Tests are currently ongoing.

FSU Threads and Open Server 3.0 or Open Desktop 3.0
FSU pthreads can be compiled with SCO 4.2!! Use a good port of GCC
2.5.X
[email protected], [email protected]
OpenServer 5.0.7 mp3/up3/supp3 has a UDK libthread.so.1 threads
library. This can be used to write threaded applications using the UDK
development tools. It contains both POSIX and UI API interfaces.

This is still a user-space threads library (because OSR5 has no kernel
threads); it is a version of the UnixWare 7 libthread, modified to
operate under the assumption that the number of available LWPs is
always one (which is the case with no kernel threads).

Thus, you will see no performance benefit from using this threads
library on MP systems. However, it does have better asynch I/O and
libc synchronization than other OSR5 third-party user-space libraries
(FSU, Pth) and so is recommended for use in UDK-based applications.
The Java 1.4.2 implementation on OSR5 mp3/up3/supp3 also uses this new
UDK libthread.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Where to get STL for SCO C++?
Here's the modern answer. Beginning with the UDK 7.1.1b release in Nov
2000, a full and high-quality implementation the entire C++ Standard
Library, including all of STL, has been available as part of the SCO
UDK product for both UnixWare 7 and OpenServer 5. There is no need to
look anywhere else for STL.

The sections that follow are for historical interest only, or perhaps
for people on very old versions of OSR5 or UW7.
[email protected]
Here's the short answer. STL is not part of the UDK yet, but we're
working on it. In the meantime, use the good freeware STL from Silicon
Graphics. A packaged version of SGI STL 3.11, adapted for use with the
UDK C++ compiler, is on Skunkware at
http://www.sco.com/skunkware/devtools/index.htm#stl . See the
README.SCO inside there for a description of how to use it.
[email protected]
Here's the long answer.

There are four commercial sources for the Standard Template Library:
Modena, ( [email protected] )
Rogue Wave ( http://www.roguewave.com ),
Dinkumware ( http://www.dinkumware.com )
and
ObjectSpace (http://www.objectspace.com/toolkits/ ).

These vendors generally sell the STL either on an OEM basis to compiler vendors
,
or as part of large site licenses. In other words, it's hard to get a single
user license, especially for SCO platforms.

There is also an up-to-date, public domain version of STL:

Silicon Graphics ( http://www.sgi.com/Technology/STL )

This is the best bet for using on SCO platforms. We have a packaged version
of it for UDK C++; see the "short answer" above.

Note: As of July 1997, the ObjectSpace STL is now also available free for
commercial use. However the ObjectSpace download page only offers it in package
d
form and for only a few platforms. The Solaris 2.5 and Windows 95 versions have
been downloaded and unpacked but they are tailored for the compilers on those
platforms and efforts to build them show that it would be a lot of work to get
them to compile with the UDK C++ compiler (partly because every C++ compiler
supports different new features right now, and partly because the
auto-configuration tool they use is not included in these distributions).
I can't unpack their MIPS/Irix version, which is the only one compiled
against an EDG-based compiler, because their install tool is an executable
program. ObjectSpace has told me in e-mail that they have no plans to
distribute a source code only, configuration-tool-included version of their
STL, so I can't be too hopeful of making use of it on SCO platforms

In addition, versions 2.6.2 and later of libg++ (the GNU C++ library) include a
t
least a part of the STL that works with GNU C++. However as of egcs libg++
has been trashed and has been replaced by the SGI version.

There is also the original public domain version from Hewlett-Packard that is
still available, but it is inferior to the current one from SGI, from which it
is based. (Alex Stepanov, the inventor of STL, now works for SGI.)

OpenServer and UnixWare 2.x C++

The native OpenServer 5.0 C++ compiler is Cfront-based, and thus will have an
impossible time compiling most STLs. At one time, ObjectSpace said that their
STL had been specially modified to compile with Cfront, in which case OSR5 C++
should work. Don't know if this is still the case.

We have not recently tested any of the STLs against the native UnixWare 2.0 or
2.1 C++
compilers. At one time they all could build, but the STL code may now be assumi
ng more
advanced compiler features.

In both cases, you're *much* better off moving to the UDK, because it supports
many more of
the advanced template features that STL relies upon and takes advantage of.

[email protected], [email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Software packaging and distribution options for OpenServer & earlier
releases
My advice, at this point, is "just say no" to CDMT. The CDMT tools
generate a format known as SSO's that can only be read by OpenServer
that is an evolutionary dead end. They're not going to be supported in
UnixWare 7, and they're not supported by the OS versions prior to
OpenServer. Walk away while you can. I would be remiss to not point
out the widespread public opinion that SSO's, custom+, cdmt, and the
rest of this way of life are, uh, not going to win any popularity
contests.

There is a TLS on ftp://ftp.sco.com/TLS/tls602.ltr that contains some
more information on how to make SSOs if you insist.

There is a TLS on ftp://ftp.sco.com/TLS/tls036.ltr that contains the
Software Mastering Toolkit (SMT) that lets you build "classic custom"
volumes that will install on any SCO Unix release.

[email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Issues if you develop on 5.0.4 and run on earlier OpenServer
Bela Lubkin, in the newsgroup, wrote:

The OpenServer 5.0.4 development system adds a few function calls
which were absent in 5.0.0 and 5.0.2. Most of these were actually
intended to be in 5.0.0, but weren't ready in time. Kernel support for
all of them is already present in 5.0.0, so programs compiled in 5.0.4
would work on 5.0.0, except that there are potential shared library
issues.

Of the new functions in 5.0.4, only four of them represent new entry
points in the shared libraries. These are fattach(), fdetach(),
makecontext(), and mkstemp(). As long as you don't call any of those,
I can think of no reason that your programs compiled on 5.0.4 would
not work on 5.0.0/5.0.2.

If you *do* call any of those functions, your programs will only work
if you avoid calling the dynamic shared object versions of the
functions. There are three ways to do so:

1. Compile COFF binaries (the default compilation mode). Advantages:
if you stick to the right subset of system calls, COFF binaries
will work on SCO Unix 3.2v4.2 and earlier; also, statically links
in functions which will work on 5.0.0/5.0.2 kernels, but which are
not in the shared objects on those systems. Disadvantage: binaries
much larger.

2. Compile static ELF binaries (`cc -belf -dn`). Advantage:
statically links in functions which will work on 5.0.0/5.0.2
kernels, but which are not in the shared objects on those systems.
Disadvantage: binaries much larger.

3. Compile dynamic ELF binaries (`cc -belf`), but statically link in
those functions. Technique:

$ mkdir /tmp/newlib
$ cd /tmp/newlib
$ ar xv /usr/lib/libc.a fattach.o fdetach.o makectxt.o mktemp.o
$ ar rv libstatic-stuff.a *.o
$ mv libstatic-stuff.a /local/lib
...
$ cc -belf foo.o bar.o -L/local/lib -lstatic-stuff -o foo

Advantage: preserves binary size advantage (and cross-OS-
compatibility) of dynamic ELF, while avoiding symbols that won't
resolve on 5.0.0/5.0.2. Disadvantage: more effort.

>Bela<

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Issues when compiling on OpenServer, executing on 3.2v4 or earlier
This contribution is a conversation between Samuel Liddicott
[email protected] and Bela Lubkin [email protected]

Sam>> Am I right in understaning from your message that a program might
Sam>> conceivably compile to COFF and fail to run on 3.2v4.2? Even if its all
Sam>> staticly linked (however you do it [I'm a delphi man]). If so then
Sam>> I need lot of thought.

Bela> Your understanding is correct.

Bela> System calls are made by calling a generic kernel entry point with a
Bela> system call number in a register. Newer system call numbers will be
Bela> rejected by the old kernel. There is no compile-time protection against
Bela> this. If a program calls one of the newer system call numbers on an
Bela> older kernel, it will get a signal (SIGSYS) and die, unless it's
Bela> arranged to trap or ignore that signal.

Bela> [about readv/writev]: the main place it's likely to matter is in network
Bela> programs. writev, in particular, helps ensure that data is sent as a
Bela> single network packet instead of many smaller ones. Could be a serious
Bela> performance issue if the program thinks it's using a real writev and
Bela> tries to take advantage of it. A well-written program will probably
Bela> have something like:

Bela> #ifdef HAVE_WRITEV
Bela> ... code that uses writev
Bela> #else
Bela> ... code that constructs a buffer and calls write() once
Bela> #endif

Bela> So it would be better if they didn't find writev() at all. But other
Bela> programs may not have such ifdefs, or they may be using writev just for
Bela> convenience and wouldn't be harmed by a multi-write implementation.
Sam>> As far as fattach or fdir go, if a program "CAN" be compiled for 3.2v4.2
is
Sam>> it then presumed that there are compiled time #def's to stop it trying t
o
Sam>> use those functions? Which I just set (perhaps by hand if a configure
Sam>> script got it wrong?)

Bela> No, that's the whole point of this discussion. You can freely call
Bela> these things and nothing will stop you, except the program will fall on
Bela> its face on 3.2v4.2.

Sam>> Otherwise, presumably I just wait for the errors to come up at compile
Sam>> time, and see why, look for any compile time flags to choose the right
Sam>> version, if not plug in my own and send in a patch?
Sam>> Finally, have I missed any gotchas, in which it might seem to work, but
Sam>> fail? [Presume I have done what you said and compiled a library that has
n't
Sam>> IDEA: What can I do with the "best no-devsys devsys" as found in
Sam>> kuso.shef.ac.uk? Maybe IT has the right libraries, which might WORK and
Sam>> STOP a configure script detecting these dodgy calls?

Bela> The SCO XENIX/DOS Cross Development Supplement will
Bela> work in that respect. It provides a compilation environment which uses
Bela> its own libraries, which have none of the new functions. Essentially
Bela> the ODT 3.0 libraries, though perhaps some bugs were fixed.

Bela> Meanwhile, as I said, here is a script which implements some form of
Bela> back-portability ftp://ftp.armory.com/~filbo/makelibv42.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
C++: Using STL in a library and I get link errors from it - Now what?
I'm building a static library and the link errors seem to reference things
from the STL that were used in the library - what gives ?

One possibility is that the necessary instantiations weren't done when
you formed your library. Try using the "CC -Tprelink_objects" command on
the .o's that go into the library, before doing the "ar" step that forms
its archive. Like this:

CC -c a.C b.C c.C
CC -Tprelink_objects a.o b.o c.o
ar rv libfoo.a a.o b.o c.o

I can't be sure this will solve your problem but it's the first thing
to try.

Diagnostics coming out of STL are legendary for being hard to understand ...

[email protected]
The above CC -Tprelink_objects step is generally necessary when
preparing an archive that contains internal template instantiations.
There is a known problem in doing this. If multiple archives are being
linked against, it is quite possible that you will get multiple
definition errors coming from common template instantiations occurring
in multiple .o files. We are currently working on a solution for this
problem in our next release. For work-arounds, you either have to
restructure your source files, or build with CC -Tlocal (which will
blow up object sizes significantly).
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
C++: I'm building C++ source with the UDK and I get warnings about
'omission of explicit type is nonstandard ("int" assumed)'
The error is that "implicit int" is no longer allowed in C++.

Assuming you don't want to fix up the source, but just want to get rid
of the diagnostics, here is a technique to suppress the warning messages :

1) Get the compiler to tell you what the error numbers are when
diagnostics are displayed using
-Wf,--display_error_number

CC -c -Wf,--display_error_number whatever.C

2) Modify the build with switches to suppress that diagnostic.

-Wf,--diag_suppress -Wf,838

CC -c -Wf,--diag_suppress -Wf,838 -c whatever.C

e.g.
CC -c -Wf,--display_error_number w.C
"w.C", line 1: warning #838-D: omission of explicit type is nonstandard ("int"
assumed)
CC -c -Wf,--diag_suppress -Wf,838 -c w.C

[email protected]
As of the UW 7.1 UDK, this general technique for selectively
suppressing warning messages is documented in the CC man page.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Where to get ANSI/ISO C++ standard library for SCO?
As of the UDK 7.1.1b release in Nov 2000, a full high-quality
threads-safe supported version of the entire ANSI/ISO C++ Standard
Library is available as part of the UDK development kit for UnixWare 7
and OpenServer 5. There is no need to look anywhere else.

The entries below are for historical interest only or possibly for
people using really old versions of UW7 or OSR5.
[email protected]
The UDK C++ compiler does not yet contain a full implementation of
the draft ANSI/ISO C++ Standard library. In addition to the
Standard Template Library (STL), which is covered by a separate
FAQ entry, the new standard library includes:

* language support and diagnostic classes
* new, templatized versions of the iostreams and complex classes that
were in the old de facto AT&T standard library
* a number of new facilities, such as strings, locales, and valarrays
(for Fortran-wannabe numeric computation).

The current SCO UDK C++ fully implements the language support and diagnostic
classes (clauses 18 and 19 of the draft standard).

The current SCO UDK C++ does not implement the new standard versions of the
iostreams and complex classes, but rather still contains the old
non-templatized versions, slightly updated for new types such as bool.

The current SCO UDK C++ does not implement any of the new facilities.

Three commercial STL vendors -- Modena, Rogue Wave, and Dinkumware -- also
market full standard library implementations, but on an OEM or large site
basis, that is generally not available for SCO platforms.

There are free implementations of the following parts of the library.
(If these links get out of date, try consulting the comp.std.c++ FAQ at
http://reality.sgi.com/employees/austern_mti/std-c++/faq.html#C6
for where to get them from.)

string

A partial implementation of the string class is available that Modena wrote;
it is at http://aw.com/cp/musser-saini-source.html .

The file bstring.h in it needs one change to compile under UDK C++: change
the #ifndef __BOOL_DEFINED on line 36 to

#ifndef _BOOL

The ObjectSpace free STL distribution also includes a string implementation,
but building it has the same problems as building their STL (see above).

valarray

A partial implementation of valarray is available that Daveed Vandevoorde
wrote; it is at ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray . The Rel2_0Beta2
version there needs one change to compile with the UDK C++ compiler: add the
lines

#ifdef __USLC__ /* SCO UDK C++ */
# define COMPILER_RECOGNIZED
#endif

at line 43 of file valplat.h.

[email protected]
EGCS, the Enhanced GNU Compilation System includes the SGI
implementation of STL and the necessary modifications to make it work
with EGCS.
EGCS is available at http://egcs.cygnus.com.
[email protected]
The SGI STL 3.11 is now available for UDK C++ platforms in packaged
form on Skunkware, with modifications made that are necessary to
compile under UDK C++.
In addition to STL, this contains implementations of the string,
bitset, and auto_ptr classes from the ANSI/ISO C++ standard library.
To get it, go to http://www.sco.com/skunkware/devtools/index.html#stl
.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
My existing C++ code doesn't compile under UDK C++!
There are a number of source and binary compatibility issues that
arise when moving applications built with SCO OpenServer C++ or SCO
UnixWare 2.x C++ to the new SCO UDK C++ compiler.

These are discussed in a white paper published in SCO CoreDump Volume
6, located at http://www.sco.com/developer/core6/c++.htm .

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Recommended books on UNIX internals
Most text from Bela Lubkin ([email protected])

There are many excellent Unix internals books. Look for:

John Lions, " Lions' Commentary on Unix 6th Edition with Source Code",
Peer to Peer Communications, 1996 ISBN 1-57398-013-7. This title was
long-suppressed by AT&T until SCO bought the rights to System V and
therefore became the copyright owner of Sixth Edition as well, and
allowed it to be published. More info is at
http://www.peer-to-peer.com/catalog/opsrc/lions.html.

Maurice J. Bach, "The Design of the UNIX Operating System", Prentice
Hall 1986. ISBN 0-13-201799-7. Based on SVR3.0, but still sets the
standards for the books on SVR4.0 and BSD. Often used as a textbook.

Steve Pate, "Unix Internals: a Practical Approach" Covers SCO
OpenServer Release 5 internals.

Berny Goodheart & James Cox, "The Magic Garden Explained: The
internals of UNIX SystemV Release 4.0", Prentice Hall, 1994 ISBN
0-13-098138-9. Builds on the Bach book but contains information on
vnodes, unified VM system, and other things new to SVR4.

Leffler, McKusick, Karels, Quarterman, "The Design and Implementation
of the 4.3BSD UNIX Operating System", Addison Wesley, 1990, ISBN
0-201-06196-1. This is the famed "Devil Book", named after the cute
little demon on the cover named "Chuck". It is to 4.3BSD what Bach is
to SVR3.

McKusick, Bostic, Karels, Quarterman, "The Design and Implementation
of the 4.4BSD Operating System", Addison Wesley, 1996, ISBN
0-201-54979-4. An updated version of the above. Reflects innovations
in 4.4BSD.

Uresh Vahalia, "UNIX Internals: The New Frontiers", Prentice Hall,
1996, ISBN 0-13-101908-2. Covers many of the new strains of UNIX that
are unique including SVR4.2, Solaris, Digital UNIX, 4.4BSD, and Mach.
Topics include kernel multithreading, multiprocessor and realtime
systems, journaling filesystem, and modern memory management.

[Append to This Answer]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. : (Category)
SCO Development Environments. :
Using FSU Pthreads on SCO systems
Issues and answers for people using FSU Pthreads on SCO Systems
Most of these come from the maintainer of FSU Pthreads for OpenServer,
ARTURO MONTES.
[email protected]
Subcategories:
Answers in this category:
(Answer) Are SCO development libraries reentrant in FSU pthreads?
(Answer) Using FSU pthreads my memory grows and grows. What is
happening?
(Answer) Can I use FSU pthreads as a shared library?
(Answer) Which system calls are FSU pthread aware?
(Answer) How can I build FSU pthreads on my OpenServer system?
(Answer) FSU threads 3.14 can be download on ftp.zenez.com
[New Answer in "Using FSU Pthreads on SCO systems"]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
Are SCO development libraries reentrant in FSU pthreads?
The answer is almost YES, if SCO claims that its libraries function
are reentrant they must be reentrant with FSU pthreads. FSU pthreads
on OpenServer tries to use the SCO scheme to make reentrant library.
ARTURO MONTES
[email protected]
Can anyone clarify this answer? I can't parse it.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
Using FSU pthreads my memory grows and grows. What is happening?
FSU pthreads use GNU malloc package. You must link your FSU pthreads
software with GNU malloc provided with FSU. In other way you will get
the previous error. Link with libmalloc.a or with gmalloc.o in FSU
pthreads.
ARTURO MONTES
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
Can I use FSU pthreads as a shared library?
Yes. FSU pthreads come in two flavors: static library and shared
library. However, when you use FSU pthreads shared library must to
take care of the library order in the command linker line. FSU
pthreads use some function in socket library, but FSU make some of
them pthread aware. Use always -lgthreads -lsocket -lgthreads, to
always use FSU pthreads socket reentrant functions.
ARTURO MONTES
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
Which system calls are FSU pthread aware?
They are: read, write, getmsg, connect, accept, select and wait system
calls.
ARTURO MONTES
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
How can I build FSU pthreads on my OpenServer system?
Run ./configure in threads/src directory and select the SCO OpenServer
option. This command copies Makefile.SCO5 to Makefile. Run make and
everything is OK. To install in default /usr/include directory, login
as root and cd to thread/src directory, run make install.
ARTURO MONTES
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. : (Category) Using FSU Pthreads on SCO
systems :
FSU threads 3.14 can be download on ftp.zenez.com
You can download it from ftp.zenez.com with the link below.

ftp://ftp.zenez.com/pub/zenez/prgms/FSU-pthreads-3.14.tar.gz
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
OLD GDS (as on Skunkware) vs. New GCC 2.95.X or GCC 3.0.X
To find out what GCC and developer tools are available take a look at

http://www.sco.com/developers/products/devkits.html

The main GCC site is...

http://gcc.gnu.org

EGCS and GCC merged. SCO now has many Gnu binaries available.

Skunkware is available at
ftp://ftp2.sco.com/pub/

The Below is for historical purposes.

---------------------OLD----------------------------------------------
------

Now that GDS looks like it's getting dusty, and there are shiny new
releases on ftp://ftp2.caldera.com/pub .
Please start using the newer GCC. GCC Advantages relative to GDS

GCC contains newer optimizations and can generate hotter code for some
input.

GCC is a much newer G++ base and much more closely reflects the state
of a useful C++ implementation.
This below is left for historical purposes.

GDS as found on ftp://ftp2.caldera.com/pub/Skunk96
It's prebuilt and custom installable, so anyone can make it go with
very little effort.

It's self-contained and absolutely works well without the native DS.
Assemblers, debuggers, and all that stuff are all there and they just
work.

It has much air-time - it's on probably thousands of machines around
the planet and robertl has almost a dozen postcards to prove it. :-)

Disadvantages of GDS relative to either EGCS or GCC.

It's based on the 2.7-ish GCC which does have some problems on x86
targets with higher optimization levels. However, many people have
compiled many megabytes of code and never encountered any of these
problems.

It's based on the 2.7-ish GCC which means that it reflects the level
of C++ that was implemented in GCC at that time. It certainly does not
track the standards as they exist in '98 very well.

It's an evolutionary dead end. This package works very well, but the
better road to take is to be sure that the newer packages all "just
build" from this one rather than trying to make more releases fo this
one that track all the component revisions.

Robert Lipe, the author of the OpenServer specific parts of GDS, was
involved very heavily with the OpenServer specific parts of EGCS. EGCS
is available at http://gcc.gnu.com and mirrors. Kean Johnston also
joined in the fun and together, they spent about a billion hours each
hammering on this code. It, too, has good things and bad things.

EGCS Advantages relative to GDS

EGCS contains newer optimizations and can generate hotter code for
some input.

EGCS is a much newer G++ base and much more closely reflects the state
of a useful C++ implementation in 1997.

See also:

http://gcc.gnu.org

EGCS Disadvantages relative to GDS

Not currently custom-installable. Key members of the Skunkware team
are believed to be working on it.

Currently requires the SCO assembler. No, getting clever and stealing
the assembler out of the GDS will get you nowhere. 5.0.4 allegedly
includes the assembler. 5.0.0 and 5.0.2 definitely do not. So if you
don't have the SCO DS and you have 5.0.0 or 5.0.2, this is a problem.

Non-trivial resources required to bootstrap it. It takes rjlhome
(dual-processor P100) about two hours and almost 200Mb to do a full
'make bootstrap'.

A full comparison of EGCS vs. GCC can be found at
http://gcc.gnu.org/faq.html. I prefer EGCS becuase it's a more open
environment, archives of the lists are on-line, and it is a much more
integrated package - all the C++ libraries (as well as g77 and
objective-c) are there and tested weekly on dozens of targets. I
really feel it's a better tested release.

I could probably come up with more compelling reasons to further
confuse the issue, but I think if I had to optimize the heuristics
used, it would be, "If you don't have the SCO DS, stay with the GDS
right now." Given a choice between EGCS and GCC, I'd used EGCS.
Ultimately, someone will take the time to make EGCS work well with the
free assemblers so that a binary distribution of EGCS would be useful
for the 5.0.0 and 5.0.2 users. I just haven't had the time to do it,
but I can point someone with suitable motivation to a couple of docs
I've written on the issues involved.
[email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Building Shared libraries with GCC or SCO cc
[ Answer by Bela and Robertl ]

SCO cc GDS EGCS or GCC >= 2.8.0
============== =============== ==============================
Make things to go into .so
-belf -KPIC -belf -fpic -fpic

Make a .so
-belf -G -belf -G -G

Use a .so
-belf -belf

Everything is identical between SCO's cc and GDS except the spelling
of the "generate position-independent code" option.

GCC 2.8.0 and EGCS 1.0 default to ELF, making the flag to emit ELF
unnecessary.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Will UnixWare 2.1 or 7.0 run ibcs/OpenServer binaries?
The short answer is "yes".
UnixWare 2.1.x still has all of the iBCS compatibility support in it
and will run OpenServer COFF binaries. You will, however, have to
avoid using any of the newer OpenServer features in your program since
the level of COFF support that exists in UnixWare 2.1.x is
approximately equivalent to SCO ODT 3.0.

UnixWare 7 product has a much higher level of compatibility with
OpenServer and should be able to run pretty much any OpenServer binary
(either COFF or ELF), except ones which rely on some very specific
knowledge of OpenServer (eg debuggers, file system repair utilities /
defragmenters, or programs which interact directly with the C2
security features and libprot)

UnixWare 7 also comes with a development environment (the UDK) which
enables you to build ELF binaries which will run on UnixWare 7 *and*
on UnixWare 2.1.x *and* OpenServer 5.x (in the latter two cases this
requires the installation of a set of comaptibility libraries on the
target platform, but these are provided and are freely available).

For future development work you may find that the UDK is the best way
to go since it gives you compatibility across all three platforms and
access to the latest versions of the language tools (C, C++, Java) and
debuggers etc.

Answer by Michael Davidson in comp.unix.sco.programmer.
[email protected]
Note that UnixWare 7.0.1 removed support for XENIX x.out binaries.
These aren't ibcs or OpenServer binaries but are an older standard.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Building GCC 2.8.0 on OpenServer results in alloca link failure early
during the build.
GCC 2.8.0 is a distraction. Use EGCS (http://egcs.cygnus.com) or GCC
2.8.1.
[email protected]
GCC 2.8.0 finally shipped. Yippie! So you grabbed it, saw that
OpenServer is finally a supported target, did the configure, typed
'make bootstrap' and watched it die within seconds on the following
error:

cc -DIN_GCC -DHAVE_CONFIG_H -o cccp cccp.o cexp.o prefix.o \
version.o obstack.o ` case "cc " in "cc") echo "alloca.o" ;; esac `
undefined first referenced
symbol in file
alloca cccp.o
ld fatal: Symbol referencing errors. No output written to cccp
gmake: *** [cccp] Error 13

Bummer.

There is one solution and one workaround. The problem is in
config/i386/x-sco5. Edit the line that looks like it reads "CC = cc"
and remove the trailing space after the last lowercase c. After you've
done this, you'll need to rerun configure so that it can rebuild all
the Makefiles. If you look at the above compilation line more
carefully you will see that there is an extra space and that is
resulting in alloca.o not being linked into the resulting executable.

Alternately, you can just type "CC=/bin/cc make bootstrap" and not
have to edit anything.
A patch to cure this was submitted to the GCC team on the day that GCC
2.8.0 was released.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
I installed GDS or GCC binary kit and nothing works.
All of the binary distributions for GCC on OpenServer have
instructions with them. Reading those instructions really is a pretty
good idea. All these kits require the SCO-provided libraries, headers,
and related tools.
Citing the instructions for GDS that are found at
ftp://ftp.zenez.com/pub/zenez/gcc/sco_ds.html :
Invoke custom
Select "Install New" option from the "Software" menu.

Follow the prompts to steer custom toward the original media you used
to install OpenServer 5.

Select Application Development Libraries and Linker. Install it all.
This will give you the libraries, headers, and man pages.

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
When I run gcc on osr5 I get "cc: installation problem, cannot exec
`cpp': No such file or directory"
You ( or more likely configure) are running gcc with -belf and the gcc
version doesn't understand it. (gcc 2.7.2.3)

change the Makefile or configure script setup from -b elf to -m elf
(or remove it altogether)
The default is to use -m elf
[email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Building Perl5.005_03
Perl 5.005_03 builds cleanly with OSR 5.0.5 cc. Make sure you have
installed rs505a, oss497a, and oss499a.
I have found you need ftp://ftp.zenez.com/pub/zenez/perl5/h2ph.PL.
This file needs to be placed in the utils directory instead of the one
there. Then do a perl h2ph.PL and copy the file to /usr/local/bin.

I have found that this patch to Config.pm in
/usr/local/lib/perl5/5.00503/i386-sco/Config.pm
will allow a person to build perl with SCO cc and then use gcc to
build all the other modules. This is needed for MySQL. The SCO cc will
not work with MySQL. The patch is at
ftp://ftp.zenez.com/pub/zenez/perl5/Config.pm.patch .

To build Perl5.005_03 on UnixWare 7.1.0 you will need these files
ftp://ftp.zenez.com/pub/zenez/perl5/Configure.patch-perl5.005_03 and
ftp://ftp.zenez.com/pub/zenez/perl5/svr5.sh. You need to put the
svr5.sh file in the hints directory and run patch on Configure.
patch < Configure.patch-perl5.005_03
[email protected]
I found this news comment on the exct problem I am attempting to
solve. However, the link to the patch is invalid
ftp://ftp.zenez.com/pub/zenez/perl5/h2ph.PL
Where else can I obtain this information?
Please note temporarily ftp.zenez.com is down. I have had some
financial problems. The important files are now on...
ftp://ftp.lerctr.org/pub/zenez/ Thanks to Larry Rosenman
[email protected]
[email protected], [email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Build DBI with gcc after building perl5.005_03 with SCO cc
If you want to install DBI on OSR 5.0.5 and you built perl with cc
you need to edit the Makefile in DBI-xxx and each subdirectory.
OLD gcc or SCO cc New
CC = cc -belf (gcc -belf -fpic) gcc
CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic
CCDLFAGS = -wl,-Bexport CCDLFLAG =
LD = ld (gcc -belf -G -fpic) LD = gcc -G -fpic
LDFLAGS = -L/usr/local/lib LDFLAGS = -L/usr/local/lib
LD = ld (gcc -belf -G -fpic) LD = gcc -G -fpic
OPTIMISE = Od OTIMISE = O1

OLD
CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include

NEW
CCCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include

This is because the Perl dynaloader will not load the `DBI' modules
if they were compiled with `icc' or `cc'.

You can find a patch for DBI-1.06 at
http://www.zenez.com/zenez/perl5/DBI.patch or
ftp://ftp.zenez.com/pub/zenez/perl5/DBI.patch

$ gunzip DBI-1.06.tar.gz
$ tar xvf DBI-1.06.tar
$ cd DBI-1.06
$ cp /from/download/location/DBI.patch .
$ perl Makefile.PL
$ patch < DBI.patch
$ make
$ make test
$ make install

[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
What's the UDK link order for building Motif programs?
-lXm -lXt -lXext -lX11 -lSM -lICE -lsocket -lnsl

[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
Is UDK C++ thread safe?
Yes. In particular:

Assuming you compile with CC -Kthread, the generated code from the
compiler is thread safe. This includes static local variables with
dynamic initialization expressions, which require special guards in
this case.

Assuming you also link with CC -Kthread, the language support runtime
routines are thread safe. This means that things like exception
handling, new/delete, and static init/ctor/dtor processing all work
correctly in the presence of threads.

The C++ Standard Library is also safe for multithreaded applications.
This means that: all internal data structures in the library are
protected against simultaneous access; simultaneous access to distinct
containers is safe; and simultaneous read-only access to a shared
container is safe. Simultaneous access to a shared container with at
least one thread writing, however, must be protected by the
application through the use of mutual exclusion primitives.

The older pre-standard iostreams classes, and the old C++ Standard
Components classes, both of which are provided for compatibility with
existing applications, are not thread-safe.
[email protected]
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
On osr5 when I dlopen a shared library I get "symbol unresolved"
errors
Assuming no other problems and the symbols complained of
are from libc this is normally
due to the dll referring to symbols that are provided statically
in the linktime libc.so and not in the dynamic (runtime linked) libc.so.1.

This works fine for shared libraries that are implicitly loaded ( specified as
-l on link line) since the needed static symbols are loaded into the executable