Note: If you installed OpenServer Release 5 from floppy you must order this package separately from SCO. There is a media charge.
One popular set of UNIX development tools is the GNU packages. The Free Software Foundation (FSF) has developed a well respected set of compilers, linkers, assemblers, debuggers, and other tools as part of the SCO, I have taken one popular distribution of several of the GNU packages and integrated then into the OpenServer Release 5 environment. I chose the Cygnus release.
Cygnus provides commercial quality support for many GNU tools. Since they are the FSF chosen maintainers of many of the packages, they have in-house experts on these tools. Cygnus is a commercial business. While they do advance the state of free software, charging for support is their livlihood.
I have been working with Cygnus and the FSF to get the required changes integrated into the official versions of these packages. The patches applied to these kits have been submitted to the package maintainers. After the paperwork is cleared, you should see all this work integrated into the FSF releases. Don't ask me when this will be.
These tools are not a complete replacement for the SCO development system. If you are the business of providing commercial products for SCO systems, you really should have the SCO package. It includes the full documentation, the SCO debuggers (dbx, dbxtra, and the Motif dbXtra) plus the Optimizing C Compiler that generates thoroughly impressive code.
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.
scods-xxxxx.tar.Note: the xxxxx will be replaced by a version number in the real thing. This archive contains a custom-installable image.
You must extract these in a directory with enough space. The
files total about 12 MB when uncompressed.
tar xvf scods-xxxxx.tar
cd /someplace_with_about_7Mb_of_space
Start custom and choose install from media images. When it asks for the pathname of the image archive, feed it the pathname you used above. Alternately, you can drive it entirelyt from the command line like
custom -i -z /tmp/xxx -p SCO:gds
add /usr/progressive/bin in your
To verify that your software is installed correctly,
ls
-aLl
/usr/progressive
should show you five directories. They should be named 'bin', 'lib', 'elf', 'i486-unknown-sco3.2v5.0.0' and 'i486-unknown-sco3.2v5.0.elf'' If not, there is a problem with the installation.
The GNU documentation is provided as a separate file in this archive. It is not installable by custom, but it does work with SCOhelp. This is a mirror of the Cygnus HTML version of the FSF documentation. Note that their site also includes the documentation in other forms, including PostScript. It contains documentation for some code that I have not included in my release. It will apply almost wholescale to this project. The following exceptions are noted. All apply to the compiler, gcc.
-b elf
instructs the compiler, linker, assembler, and other tools to emit ELF.
The default is to emit COFF.
-static
When generating ELF, the default is to create dynamically linked
output. This flag overrides this and creates staticly linked
ELF output. Note that option is available only if emitting
ELF.
-Ansi
uses ANSI headers and libraries
-Compat30
uses ODT 3.0 compatible headers and libraries.
-Posix
uses POSIX headers and libraries.
-Xpg4
uses XPG4 headers and libraries.
-Xpg4plus
uses XPG4 headers and libraries, with chosen extensions fro the ODT 3.0 environment. This is the default.
If you find this work useful, find a nice postcard of your hometown and send it to:
Robert Lipe 102 Pebble Creek Road Franklin, TN 37064 USAHopefully, this will help me judge if anyone appreciates this work enough to continue to maintain it.
The good news is that the Dec '95 and later versions of the compilers
really do generate correct code in both ELF and COFF mutants. (Yes,
it is necessarily implemented differently for each object file
format.)
The bad news is that it requires new versions of the startup/teardown
files from SCO. As of this writing (11/28/95), it's yet undecided if
these will be made into a TLS or as part of an upcoming release
supplement. Also undecided are the time frames, though the worst case
date that I've heard for general customer availability is the end of
February. Don't ask me for copies of them, becuase I cannot legally
provide them.
cc foo.o
This is no longer legal. You can not mix and match COFF and ELF
compilers in this manner. When you try it, you get a rather unhelpful
error message.
This is a somewhat unfortunate side effect of making the static
constructors work correctly under COFF.
Specifically, it will set the number of shared libraries to one, even
if your program really does use more than one. You can see this
with dump, and you can correct it by manually patching the section header.
[ If you have to ask, please don't. ]
As shared library COFF programs are not generated by the current version
of either these tools or the SCO development system, I've not yet been
motivated to add the half-dozen lines of code to bfd/coff-header.h
in the #ifdef _LIB chunk of coff_set_section_contents() to actually
count these sections by counting the number of entries in each .lib
section [ respecting padding ] and adding them up instead of setting
it to one. Since I couldn't actually test the code, it would be a
bigger disservice to the community to implement an untested fix than
it would be to leave it broken.
Thanx go to jpr@jpr.com for finding this and belal@sco.com,
Larry Philps, john@sco.com, and ian@cygnus.com for helping
me understand it.
"The problem is solved in my head. Do I actually have to solve it on a
keyboard?" Me, to my manager, 1992.
Known issues or limitations
G++ Debugging and SCO debugger interoperability
By default, the compilers generate debugging records to be
compatible with the SCO supplied debuggers. This means for COFF
object files, COFF debugging is used. For ELF, DWARF1.1 is used. G++
will not emit DWARF. This means if you are debugging C++ that was
generated with these tools under ELF, you must use the "-gstabs" flag
instead of just "-g". You must also use GDB instead of a SCO provided
debugger when debugging C++.
Static Constructors and Destructors
The startup files provided with SCO OpenServer 5.0.0 have a few
problems that are exposed by the way I implemented constructor and
destructors for G++. The most blatant place it fails is in the test
for Groff, where configure flatly states the compiler is broken.
Mixing object file formats
In SCO's CC and in my releases prior to 95.4a, the following was
legal:
cc -b elf -c foo.c
Of course, typical code is more complicated than that. A frequent
occurrence of this is when adding libraries or special link flags in
the final link.
ld foo.o fatal: Can't open file ELF for input
The solution is to be consistent with the front-end you invoke. In
this example, it would be correct to either add -b elf to
the link line or to remove it from the compile lines. I have had good
luck with net packages just by specifying CC="gcc -b elf"
configure. This seems to work pretty universally, though I can
easily imagine Makefiles that will mishandle this.
-dy differs from SCO tools
Some makefiles fro the SCO compilers invoke cc with the -dy flag
In the OpenServer 5 devsys, this means use dynamic
shared libraries, for gcc, this seems to mean dump yacc debug
information. Use -belf to achieve the same results with this gcc.
Thanks to Larry Philps for pointing this out. I have tested
dynamically linked programs built with these tools, and believe
they really do [ finally ] work right.
GNU ar differs from SCO ar
The GNU ar behaves differently than SCO's. In particular if
gnu ar is given the 'q' flag, it does _not_ put a symbol
table into the archive, and "ranlib" has to be run after that
to make the archive useable.
Thanks to Larry Philps for pointing this out, but curses and
poxes on the people through the years that think that running
another problem to "fix" an index built by a program is a good idea.
This also applies to mailers and alias tables and a few other rants,
but I digress.. SHAME!
Strip does not strip in place
The GNU strip program copies the target file to a temp file
while stripping it, then uses the rename system call to put
the temp file in place of the original.
This breaks the 4.4BSD "install" program which does a fchmod
on the file that just been replaced by the "renamed" temp file.
Thanx go to Larry Philps (see a pattern here, kids?) for
pointing this out.
GNU strip does bad things to ODT3 built COFF programs using shared libraries
This problem is not specific to my release, but is indeed a
problem in the FSF strip and objcopy programs. Actually, it's in BFD,
but you probably don't care. . If you have a COFF program
that uses shared libraries and execute the GNU strip command on
it, it will do Bad Things to the binary.Without Whom Department
Of course, any project like this is the results of the work of many.
However, some in particular stand out.