Quarterly ASCII posting of SCO Programmer's FAQ

Archive-name: sco/programmers-faq
Posting-Frequency: quarterly
Version: 1.0.1a
Last-modified: 1999/04/30
URL: http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
Copyright: (c) 1999-Present SCO Programmer's FAQ
Maintainer: Boyd Lynn Gerber <gerberb@zenez.com>
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.pl

SCO Programmer's FAQ ASCII.



(Category) SCO comp.unix.sco.programmer FAQ.
This services tries to provide answers to the Frequently Asked
Questions in news:comp.unix.sco.programmer.

Since it is based on traffic in that group, it has a definite slant
toward the SCO UNIX/OpenDesktop/OpenServer product families. However
coverage is given to the UnixWare 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://staff.ussinc.com/~steved/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 FAQ.
http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
The UnixWare FAQ
http://www.freebird.org/faq/
The UnixWare 1.x and 2.0 Programmer FAQ
http://www.freebird.org/faq/developer.html

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

It is strongly encouraged that the answers in here address
SCO-specific issues.

It is run from the Faq-O-Matic accessable at
http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl, 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) Unixware 7.x.x
(Category) How to Find FAQ
[Add a 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 is 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.
robertlipe@usa.net
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) GDS (as on Skunkware) vs. EGCS or GCC 2.8.0
(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) run gcc (osr5) and 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?
[Add a 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.
robertlipe@usa.net
[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.
robertlipe@usa.net
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
robertlipe@usa.net
[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 .
robertlipe@usa.net
[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.
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://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.

A completely self-contained DS for OpenServer that does not require
the SCO DS is available at http://www.zenez.com/zenez/robertl or
ftp://ftp.zenez.com/pub/zenez/gcc . 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://egcs.cygnus.com 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.
robertlipe@usa.net
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.
robertlipe@usa.net
[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.
robertlipe@usa.net
GDB 4.17 works well on OpenServer.
robertlipe@usa.net
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.
robertlipe@usa.net
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.
hops@sco.com
[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.
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.

robertlipe@usa.net
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.
robertlipe@usa.net
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.
dfp@sco.com
[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()
robertlipe@usa.net
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.)
jls@sco.com
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

hops@sco.com
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

hops@sco.com
In the UDK and in UW7, there is an intrinsic version of alloca() built
into the compiler. It is enabled via -Kalloca.
dfp@sco.com
[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: insure@parasoft.com
HTTP: http://www.parasoft.com

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

robertlipe@usa.net
checkergcc exists for linux. Could probably be ported to SCO systems.
robertlipe@usa.net
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.

jls@sco.com
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.
robertlipe@usa.net
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.
robertlipe@usa.net
dmalloc (www.dmalloc.com) works fine with OSR5.
john@kuwait.net
[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.
robertlipe@usa.net
[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.

robertlipe@usa.net
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
}

hops@sco.com
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

}

hops@sco.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) SCO
Development Environments. :
How to write dialers
look at ecu, XC
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.
robertlipe@usa.net
[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.

jls@sco.com
[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 three popular compilers on SCO OpenServer.

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.

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.

robertlipe@usa.net
[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 mitosys@colomsat.net.co 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/li...reads/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. A modified to work with OpenServer is
available at

http://www.cs.wustl.edu/~schmidt/ACE...threads.tar.gz or
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
gerberb@zenez.com, robertlipe@usa.net
[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 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.
jls@sco.com
Here's the long answer.

There are four commercial sources for the Standard Template Library:
Modena, ( modena@netcom.com )
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.

robertlipe@usa.net, hops@sco.com, jls@sco.com
[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.

robertlipe@usa.net, steved@ussinc.com
[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<

robertlipe@usa.net
[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
sam@campbellsci.co.uk and Bela Lubkin belal@sco.com

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.

robertlipe@usa.net
[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 ...


hops@sco.com
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).
jls@sco.com
[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

hops@sco.com
As of the UW 7.1 UDK, this general technique for selectively
suppressing warning messages is documented in the CC man page.
jls@sco.com
[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?
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/aus...++/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.

jls@sco.com
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.
robertlipe@usa.net
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