GNU Development Tools For SCO ( 21-Dec-1996)

Overview

Beginning with the OpenServer Release 5 product, SCO ships a product called the "Application Development Libraries and Linker" on all CD and tape distributions. This allows use of third party development tools to be hosted on OpenServer Release 5 systems without requiring licensing of the SCO Development System.

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 GNU project. These packages are available under the COPYLEFT agreement.

With the help of 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.

What is provided and why.

I chose only a subset of the Cygnus tools to redistribute in binary form. I did not provide things like Objective C, the DejaGNU test suite, or the TCL kits. I chose the amount of commands to allow an SCO user to to compile, debug, and execute most programs. I did not perform extensive testing on these tools, although I have used them to rebuild themselves. I have run the Cygnus 'make check' on most of the tools, and they do have a fairly large user base. I decided (arbitrarily - a right I have as a provider of free stuff) that providing a minimal toolset would allow people to build and port these and other programs to OpenServer 5. I hope others do exactly this.

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.

Using these packages

You must have OpenServer Release 5. These absolutely, positively, will not do anything productive on any earlier release. To help drive this point home, I have provided only ELF binaries. They will flatly fail to execute on earlier releases.
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.
The distribution is provided as a tar archive named scods.xxxx.tar.Note: the xxxx 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.
cd someplace_with_enough_space
tar xvf scods.xxxx.tar
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 entirely from the command line like
custom -i -z directory_specified_above -p SCO:gds
add /usr/progressive/bin in your $PATH
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.

Using the tools

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.

Bribing the Contributor:

Patches and enhancements are welcome.
Complaints about the GNU versions I used are not.
Suggestions are accepted.
Whining is not. ;-)

If you find this work useful, find a nice postcard of your hometown and send it to:

		Robert Lipe
		1800 Susan Court
		Franklin, TN  37064  USA

Hopefully, this will help me judge if anyone appreciates this work enough to continue to maintain it.

Revision History

09/95 Initial versions.

Built upon Cygnus progressive-95q2.
The versions on Skunkware and on the archive site were nearly identical. The source was nearly identical, but there were some differences in way they were built.

12/01/95 95.4a - beta only
Built upon Cygnus progressive-95q4.
Began using version numbers. I use "95.4a" to signify the Cygnus release. I'll increment the letter if I need to make multiple releases.
Adds GDB, including ELF support.
Adds libg++ and libstdc++.
C++ static constructors and destructors work right now. See Known Limitations
Made custom installable.
Update this document and "building" to reflect new release.
Add section on debugger interop.
12/10/95 95.4b
Fixed permissions problem when installed through custom. (Doesn't every machine have a user named 'robertl' on it? :-)
Minor tweaks to documentation, but not even a recompile of the code. It should be bug and feature compatibile with 95.4a.
12/21/95 95.4c
Include a fixed version of FSF libg++ version 2.7.2.
More tweaks to documentation, but not even a recompile of the non-libg++ code. It should be bug and feature compatibile with 95.4b.

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.

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. These are available for OpenServer 5.0.0 in the form of TLS 597 available from ftp.sco.com. This fix seems to be included in OpenServer 5.0.2 and later SCO releases.

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

cc foo.o

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.

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.

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.

This is a somewhat unfortunate side effect of making the static constructors work correctly under COFF.

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

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

Without Whom Department

Of course, any project like this is the results of the work of many. However, some in particular stand out.

Larry Philps twisted my arm into doing this with one sentence. (grumble, grumble. Tell me I'm not guru enough....) Larry also provided much testing, some documentation, and many quick answers about the SCO provided tools that we have to interface with.
John R. MacMillan was very patient with my questions ranging from the undocumented to the blatantly documented. He unraveled the mysteries of the .notes section and many geeky details on the linker internals. He put up with me disassembling SCO object files and sending him patches. He spent much time working with me to get the C++ support correct. I learned a lot from him. Thanx, John!
Many SCO employees that actively monitor Usenet including Bela Lubkin, Dion Johnson, Tim Ruckle, Jim Sullivan and others, for listening to the feedback about the need of freely available libraries, headers, etc. and helping to make it happen by passing that feedback on.
Several SCO employees that helped me through tough times in making friends with the CDMT tools. Since they didn't respond to me publicly, I respect their anonymity. Without their help, it would not be custom-installable.
The documentation department at Cygnus implemented my suggestions on HTML-izing the FSF documentation and made it available in a neat little package. Thanx!
Of course, the GNU project must be thanked for providing us with such a solid code base to work from. Support them any way you can!