libg++.2.7.2.3.README May 29, 1998 These archives contains the following pre-built libraries of libg++-2.7.2. These libraries can be used with any gcc compiler, version 2.7.2.x. Currently, this includes: 1) cc as distributed with OpenStep for Mach 4.2 Developer packages. 2) Any other gcc 2.7.2.x. This libg++ distribution has been made to complement my port of gcc for OpenStep (version 2.7.2.3.3). See the USAGE section for more details. file: libg++.2.7.2.3.m.NIS.bd.tar.gz desc: complete package for c++ developers (documentation, header files, static libs, dylibs). sum: 50339 3212 md5sum: e12ad7f9eba62307619f61272c4e1d5d file: libg++-dylibs.2.7.2.3.m.NIS.b.tar.gz desc: dylibs only, intended for client deployment sum: 14725 550 md5sum: 3e36bcec509dbacf42833297d99fd13f NOTES Regarding the versioning of this package: I tacked on my port attempt numbers to the end of the gcc versions, ie, This represents my third (.3) attempt at porting libg++ v2.7.2 to OpenStep. These packages have been built for and tested on OpenStep for Mach 4.2, but may also work on others version of OpenStep for Mach 4.x. This build does NOT work on NEXTSTEP 3.x and earlier. These libraries have only been tested/used on the i386 platform. If you have success or failures on other platforms (especially sparc), please let me know. The libg++ package contains static libraries that were built with debugging (-g), but the dylibs contained there do were builts without debugging. So, if you want/need to use gdb, link against the static (.a) libs. If you require the debuggable dylibs, let me know. INSTALLATION The tar.gz archives contain the installer packages libg++.pkg and libg++-dylibs.pkg. Use Installer.app to install one or the other (not both) into /usr/local and you're done. If you want to build fat (or non-native) binaries, make sure to specify "Install software for all architectures" (in Installer.app). USAGE (libg++ package only) This GNU c++ library requires gcc version 2.7.2.x (any x will do). Compilers that can be used with this library include: gcc (2.7.2.x) cc (2.7.2.1) as included with DeveloperTools for OpenStep for Mach 4.2. Pros/Cons using gcc and NeXT's cc. gcc CON: cannot produce relocatable code (using -dynamic and/or -fPIC) reliably (ie, can't be used to produce your OWN C++ dylibs or frameworks). PRO: supports all (most?) -f flags, like -fno-implicit-templates, -frtti and -fhandle-exceptions. CON: Supports i386 platform ONLY (m68k and sparc not supported at this time). cc (mostly opposite of gcc): PRO: can produce relocatable code (using -dynamic) to produce your own C++ dylibs and/or frameworks. CON: doesn NOT reliably support optional -f* compiler flags (as listed above) (ie, the compiler dies with "Internal error"). PRO: Supports ALL platforms (m68k, i386, sparc), and can create FAT binaries. Tricks to using cc as c++ compiler: Envocation: Envoke the compiler as 'cc' NOT cc++. cc++ uses an Obj-C++ mode that, frankly, doesn't work too well (at least not for pure c++ code). cc will recognize c++ files automatically if the have .cc,.C,.cpp extensions. Linking: You need to explicitly specify these libraries (-lstdc++ and/or -lg++) at link time when using cc. CAVEATS The i386 port has been tweaked to at least attempt to support the -frtti and -fhandle-exceptions compiler flags. The m68k and sparc libraries most likely will not support them. HISTORY May 29, 1998 (2.7.2 port 3) - Oops, -dynamiclib method requires -arch flags for non-fat targets. hmm.. - Include pre_/post_ install and pre_/post_delete scripts in libg++-dev to handle setup details... mostly just a few symbolic links to help the compilers find header/library files. - Create gzipped packages - Fixed linking problems. Needed to create dylibS with cc -dynamiclib instead of manually using libtool, libtool -dynamic April 13, 1998 (2.7.2 port 3beta) - libio/fstream.cc requires -static when built with cc (gcc ok). - cc made binaries requires -lcc. Without it, some __builtin functions will not be found (sometimes) at runtime (yes runtime, NOT linktime). Without -lcc, it'll link against -lcc_dynamic, which, I think, is the source of this problem/bug. (Again, gcc is ok). This doesn't seem to help for Rhapsody/DR1. ??? - Fixed non-relocation warning wrt to random.o in libstdc++.a (compile w/ -O0) - Remove libg++ from gcc, put in separate package. - Modified libc.h to bootstrap bsd/libc.h (so that common c functions will no longer be undefined). CREDITS GNU Software, libg++ source http://www.gnu.ai.mit.edu/ Packager Rex Dieter Computer System Manager Universtity of Nebraska-Lincoln Department of Mathematics and Statistics http://www.math.unl.edu/~rdieter/