Subject: libcomo(tm) VER 35 Sep 25, 2006

PLEASE READ THIS MESSAGE IN FULL.  There are many details in
the discussion below, and although details are tedious, reading
this message in full will save you time and frustration in the long run.

This message contains download and install information for `libcomo'.
libcomo(tm) is the Comeau Standard C++ Library VER 35 for use with
Comeau C/C++(tm) 4.3.8

ANY ADDITIONAL RIGHTS TO Comeau C/C++.  If you have any questions,
then email us

libcomo has been modified to work with Comeau C++ 4.3.8 on
MS-Windows (XP, ME, 2000, NT, 98 and 95), Solaris/SPARC, SunOS 4.x.ys, NetBSD,
"older" LINUX/INTEL/ELFs, SCO UNIX, and UNIX 3/486 SVR3's.  For a more
complete list, and other information about libcomo, see

This VER 35 version of libcomo is available in a compress'd cpio'd
version at:

If you do this by hand, make sure that you download in "binary" mode.

therefore that some files may have cr/lf as their newline delimiter)
and for additional Windows requirements and concerns.

Upon downloading the above file, you should note that its size should be:

  -rw-r--r--   1 comeaump  comeaump  753177 Sep 25 11:11 libcomo35.Z

Once you uncompress it, its size should be:

  -rw-r--r--   1 comeaump  comeaump  2365440 Sep 25 11:11 libcomo35

Make a directory somewhere (it's best not to use an existing directory,
so create a new one instead), say /como438/libcomo, then uncompress
and un-cpio it.  Below is a sample shell script to install:

set -vx

to=/como438     # CHANGE THIS

cd $to
mkdir libcomo
cd libcomo
ls -la libcomo35.Z
uncompress libcomo35.Z
ls -la libcomo35
cpio -ivcdIlibcomo35  # An upper case "eye" is immediately after the d
rm libcomo35

Now that the files have been installed, you may need to build
libcomo as explained below.

Notes for MS-Windows users:
libcomo is now available for use with Comeau C++ under MS-Windows
with the following backend C compilers:

* MSVC++ 8.0
* MSVC++ 4.0-6.0
* MSVC++ 7.0
* MSVC++ 7.1
* Borland C++ Builder 5.x (either their commercial compiler or
  their free 5.5.1 version),
* Borland C++ Builder 6 (compiler version 5.6.x)
* MinGW (the "mingw special" gcc version 2.95.3-6 and above),
  Note that other versions of MinGW, or gcc's from different
  sources, will currently not work, nor will gcc 3.x's or 4.x's
* lcc-win32 from "Feb  3 2002 09:47:54", also from "Aug 31 2003 13:37:11"
* Digital Mars C version 8.26.3n, also 8.34
* MetroWerks CodeWarrior version 2.4.5 build 199 and above

you'll need to upgrade your C compiler, or switch to another C compiler.

Use of any other C compiler(s) or other versions from above requires a port.

***YOU NEED*** THE 4.3.8 UPGRADE OF COMEAU C++.  If you are an
existing 4.2.x+ customer of a generally available port, then
contact us about how to obtain this upgrade.

If you would rather download a .zip version, there's:

its size should be:

  -rw-r--r--   1 comeaump  comeaump  489803 Sep 25 11:11

The .zip file contains the exact same files as the compress'ed version
above, so it need not only be used with MS-Windows (similarly, if your
software under MS-Windows can uncompress the .Z version, you can
use that with no problem too).  To install the .zip version under Windows,
make a directory somewhere (it's best not to use an existing directory,
so create a new one instead), say d:\como438\libcomo, then un-zip it
into that directory.  Below is a sample .bat file to install:

set TO=d:\como438 #CHANGE THIS
set OPTIONS="options for your specific unzip'er" # CHANGE THIS
set UNZIP=unzip # name of YOUR UNZIP command here  # CHANGE THIS

cd %TO%
mkdir libcomo
cd libcomo

Of course, if you have an interactive unzipper application
then just follow its documentation.

Note that Comeau C/C++ 4.3.8 for MS-Windows will automatically
pick up libcomo if it is placed into a directory named libcomo in
your main Comeau directory structure.  As well, this release
will recognize an environment variable named COMO_LIB_BASE containing
libcomo's location.   If you use either of these choices (but don't
do both!), you will not have to specify the libcomo include file
directory or .lib on the command line.  Some of you are still using
Comeau C/C++ 4.2.45, and below, whereas you may have specified:

    como -Id:\libcomo ...other options... file.cpp d:\libcomo\libcomo.lib

Now, with auto detection of libcomo as just described, you just need:

    como ...other options... file.cpp

Note that you should not mix these two auto choices, just use one or
the other.  Note also that if you opt for either of these choices,
and you previously used COMO_INCLUDE for the libcomo include directory,
then you should remove the libcomo directory from COMO_INCLUDE.

Again: if you create a directory named libcomo in the top-most
Comeau directory structure, then don't use COMO_LIB_BASE,
and, if you use COMO_LIB_BASE, then don't create a directory named
libcomo in the top-most Comeau directory structure.

Note that Comeau C/C++ for MS-Windows may be run in
--microsoft mode and --microsoft_bugs mode -- the default mode.
In previous versions of Comeau C++, due to extensions in the VC++
header files, it was necessary to deal with some VC++ issues by
specifying these options:

    --wchar_t --no_microsoft_bugs -D_WCHAR_T_DEFINED

However, if you use either COMO_LIB_BASE or the libcomo directory
as described above, you no longer need to specify the above options.
So, whereas previously you may have used the following with VC++
as the backend C compiler:

    como --wchar_t --no_microsoft_bugs -D_WCHAR_T_DEFINED...other ops.. file.c

you now just need:

    como file.c

As you can see, many of the command line options previously
necessary are no longer necessary.

Additionally, note that Comeau C/C++ 4.3.8 now allows you to
specify --a and --A options (two dashes) in an effort to support
Comeau C++ strict mode under Windows too, and so libcomo is
able to be *used* (not compiled itself) in strict mode under
Windows in many cases.  This should be so with the Borland, MinGW,
lcc-win32, Digital Mars and Metrowerks CodeWarrior backends too.
Give us feedback if you find this is not the case.

If you are using Microsoft as the back end C compiler,
note that YOU WILL GET ERRORS IF YOU ARE NOT USING MSVC++ 6.0, 7.x or 8.0.
That is to say, stl_config.h defines the macro __USING_MSC_WITH_COMO
and by default it is set for use with VC++ 6.0.  If that is not the case,
you must change __USING_MSC_WITH_COMO as stl_config.h discusses.
When you run makeit.bat (see below) it will tell you what the value
should be for #define'ing __USING_MSC_WITH_COMO.  If it's not right,
you'll need to hit control-C during makeit.bat, change stl_config.h,
and run makeit.bat again.  Again, note that if you have MSVC++ 6.0
(no matter which sp's you have installed) then you don't need to change
this.  You don't need to change this value for VC++ 7.x or 8.0 either.

As well, note that WE DID NOT TRY EVERY VERSION OF MSVC++, nor every
possible "sp" combo either.  We used an earlier version of VC++, 4.0,
and also 6.0, 7.0, 7.1 and 8.0 in hopes that it will shake out fixes and
enhancements that MS would have made that would impact compilation
and use of libcomo.  This means that in some cases you may not be able
to compile libcomo for Windows due to some difference that we are
unaware of.  If you run into a problem, don't hesitate to contact us
about it.  Include in the problem description which MSVC++ you have,
which sp's you have installed and the value of the _MSC_VER macro
(do a cl -E __unix.c, found in the libcomo directory).
We'll provide patches here as soon as we know them.

Similarly, we did not try libcomo with every version of Borland C++,
MinGW, lcc-win32, Digital Mars C or Metrowerks CodeWarrior.  So, if you
run into problems, we'll need to see if it is version specific or not.
As noted above, we have tried it when using VC++ 7.x & 8.0 as a backend though.

Note that in some rare cases with VC++, you may be using other libraries
that do not allow compilation with the MS single-threaded runtime library.
This will make the compile of _whichmsc.c fail, which makeit.bat compiles
as its first step when being used with VC++.  In such a case, makeit.bat
just assumes threading is the reason for the failure and tries to recompile
_whichmsc.c using the /MT command line option to specify use of the MS
multithreading run-time library.   If this is not the reason, then,
the second compile will no doubt still fail.   The compile of _whichmsc.c
is not normally expected to fail, so if it does, you probably do not have
VC++ set up properly.  NOTE: the compile of _whichmsc.c does not
use Comeau C++, it uses cl.   This means that IF YOU ARE BUILDING
AND LINK APPLICATIONS (this is necessary for any backend to work with
Comeau C/C++ anyway).  If you are not building libcomo for use with VC++,
_whichmsc.c is not compiled, so it does not matter, although you should
still ensure you can compile AND LINK applications with that C compiler
independent of Comeau C++, since that is necessary for it to work with
Comeau C/C++ too.

To compile libcomo under MS-Windows, you will need to run makeit.bat:

  C:\como438\libcomo>makeit [vc8|vc71|vc7|vc|bcc|min|lcc|dig|mw] [--no_exceptions]

Note that building libcomo without exception handling is now supported.

Note that VC++ versions don't subsume all previous ones.  Therefore,
for instance, 'makeit vc8' doesn't necessarily accommodate VC++ 7.1.
And so on.  Both version of VC++ can be installed, and both versions
of libcomo can be built but do to difference between each VC++ version
from the other, then each libcomo must be built independently.

See below for some more information about compiling libcomo yourself.

Last but not least, check
which shows you how to make changes needed with the various C compilers.
For instance, with MSVC++ 6.0-7.x you will need to make a shadow <winnt.h>,

Note to users with Borland and MetroWerks CodeWarrior as backend C:
Note that the Borland compiler and linker, and the Metrowerks compiler,
seem to have a maximum external id length of 250 characters.   It turns
out that some of the generated mangled template names are unable to
fit within that space.  Therefore, when Borland or Metrowerks is used
as the backend C compiler up until Comeau C++, we have remapped
some of the names libcomo uses to shorter names.  So short in fact we
could not get away with names beginning with underscores.  In fact, it
was necessary to map most to 2 character id names.  We believe that
libcomo is still intact with these changes, however, there are two impacts:
1) Your own programs may use some of these identifiers (although
   one could claim that's bad style)
2) Error messages will contain the remapped names and not the
   original names.

As an FYI, here was the list of names and their remapping:

#define insert_unique_noresize IN
#define _Select1st S
#define _Hashtable_iterator HI
#define hashtable _H
#define allocator _a
#define hash _h
#define back_insert_iterator BI
#define __get_monetary_value GMV
#define istreambuf_iterator II
#define basic_string BS
#define _M_ignore_unbuffered IU
#define _M_ignore_buffered IB
#define _M_copy_buffered MCB
#define _M_read_buffered MRB
#define _Scan_for_not_wspace SN
#define _Scan_for_int_val SI
#define _Scan_for_char_val SC
#define _Constant_binary_fun BF
#define _Constant_unary_fun UF
#define _Eq_int_traits EI
#define binder2nd B2
#define equal_to ET
#define pair _P
#define char_traits CT
#define eqstr Q

Note that you should continue to write your source code using the
correct names, and hopefully the remapping can be as transparent
as possible.

NOTE: Since version, Comeau C++ automatically "gets around"
this id length limit of Borland, so it can now resolve this for Borland
(obviously people ran into this problem in their own code,
not just with libcomo).

When we get conformation that everybody who ran into this
problem is ok, we will (a) remove the above #define's and
(b) implement the resolutions for Metrowerks.

So, *** PLEASE PROVIDE US FEEDBACK *** if you ran into a name
mangling problem in previous versions of Comeau C++ and/or libcomo
when using Borland so we can confirm that it is now ok with versions
of Comeau C++ after version

Note to RedHat LINUX users (and NetBSD):
With some versions of RedHat LINUX, the cpio options will need to be
-ivd not -ivcd.  Also, the RedHat cpio may not create directories
with the right permissions.  In such a case, you will need to chmod
the directories by hand.  If you don't, it may then effect some
#include and lib lookups, etc. in the sense that it may silently
use some other one in a different directory.

Note additionally that not all LINUXes or versions of gcc are the same.
Sometimes this is even true when from the same vendor for the same release.
This also seems to be the case for NetBSD, though rarer.
(or NetBSD) due to some minor but annoying difference.  If you run into
a problem, contact us about it.  Include in the problem description
exactly which OS and development system that you have.  We'll provide
patches here, or directly to you, as soon as we know them.

That said, note that CXXFLAGS in Makefile.como is set up for use
with leading edge LINUX implementations, for instance RedHat 7.x.
If you have earlier versions, you may get a successful build using
one of the CXXFLAGS definitions that are commented out.

Also, as a general remark, check
for LINUX specific issues with Comeau C/C++.

Normally, you might compile a file with Comeau C++ by saying:

  # use when set up automatically
  como file.c

However, the como'ized libcomo headers (and _in some cases_ binary library)
are available in the directory you installed them into above.
There are ways Comeau C++ can use libcomo automatically.  For
non-automatic use, using the example directory above, you would
need to type the following in order to be able to use libcomo
under say UNIX (all on one line):

  # UNIX use when not set up automatically
  como -I/como438/libcomo -I/como438/libcomo/cnames file.c

In some cases, you will need to recompile libcomo yourself in order
to obtain libcomo.a/libcomo.lib  This probably makes sense anyway,
even if a libcomo.a/libcomo.lib is provided in your case.  As usual,
this does not apply to custom ports of libcomo, as they will have
their own terms.

Note that the cnames directory provides <Cname> style headers
on some platforms, as <name.h> alternatives for "C headers".
Similarly, note that Standard C++ does not use <iostream.h>
but instead uses <iostream> and by implication then, has
std::cout, and not cout.  For some technical details here,

Note also, that as of Comeau C++ 4.2.45, the UNIX Comeau C++ install
program (NOT the libcomo install) now lets you set up the -I and .a
information automatically (even if the standard lib you want
to use is not libcomo).   This means you don't need the -I and .a
options in the last example above on UNIX.   See the discussion
above on how to set up libcomo for automatic use on MS-Windows.

Also, note that the cnames directory is not used when Metrowerks
is used as the back end C compiler.

You should recompile the libcomo library yourself.  In fact, due to
slight differences in platforms, even sometimes when of the same release,
this recompile is probably recommended.  This ensures it's really in
sync with your compiler release, sp patches, whatever.

If you have a new platform, we would be glad to consider a
custom port for you.

If you would like to recompile the library yourself, and you are using
a UNIX listed much earlier in this document, then use Makefile.como:

      # UNIX use:
      make -f Makefile.como

Note: On some LINUXes you might get errors in stdio_streambuf.cxx about
fpos and fpos_t.  If so, it may be necessary to #define __REALLY_NEW_LINUXES
in order to compile successfully.   You can do this by uncommenting
the respective CXXFLAGS line in Makefile.como (and commenting the active one)
that contains a -D__REALLY_NEW_LINUXES

As well, if you have a very recent version of LINUX, you'll need to have
-D__REALLY_NEW_LINUXES for a different reason, as fstream.cxx uses
caddr_t.  Furthermore, you'll also need to set -D_POSIX_SOURCE=1
and _D_SVID_SOURCE=1 on the CXXFLAGS line of Makefile.como.

As of libcomo 22 we've left all these -D's as the default.
If they do, use a simpler CXXFLAGS setting.

If you are using MS-Windows, then run makeit.bat, in one of the
following ways:

      REM Windows use, for use with a Microsoft VC++ 8.0 back end:
      makeit vc8

      REM Windows use, for use with a Microsoft VC++ 7.1 back end:
      makeit vc71

      REM Windows use, for use with a Microsoft VC++ 7.0 back end:
      makeit vc7

      REM Windows use, for use with other Microsoft back ends:
      makeit vc

      REM Windows use, for use with a Borland back end:
      makeit bcc

      REM Windows use, for use with a MinGW back end:
      makeit min

      REM Windows use, for use with a lcc-win32 back end:
      makeit lcc

      REM Windows use, for use with a Digital Mars back end:
      makeit dig

      REM Windows use, for use with a Metrowerks CodeWarrior back end:
      makeit mw

Make sure that you have the required versions of these C compilers,
or else problems will arise, and you will just waste your time.

Note that if you would like to use libcomo with more than one of the
required C compilers, then you can build libcomo for more than one of
them by running more than one of the above makeit's.   Note that makeit
for Microsoft will result in libComo.lib (for VC++ 7.1 it will create
lib71omo.lib, and for VC++ 7.0 it will create lib7omo.lib,
and for VC++ 8.0 it will create lib8omo.lib), makeit for
Borland will result in libBomo.lib, makeit for MinGW will result in
libMomo.lib, makeit for lcc-win32 will result in libLomo.lib,
makeit for Digital Mars C will result in libDomo.lib, and makeit
for Metrowerks CodeWarrior will result in libWomo.lib.

Therefore all flavors may reside concurrently in the libcomo directory.
Furthermore, they can be picked up/detected automatically by como.exe
if you've installed libcomo as described elsewhere.

As well, as of libcomo 21, you can specify --no_exceptions to makeit
after the C compiler designation.   This allows you to build libcomo
with exception handling disabled.   Note that in this case the library
name is appended with NX.   So, for instance, if you invoke makeit
as "makeit vc --no_exceptions" it will produce libcomoNX.lib instead of
libcomo.lib.   como.exe will also handle this correctly (by picking up
the right libcomo file) if you use --no_exceptions to compile your
source files (this assumes that you have already compiled libcomo
with --no_exceptions as the argument to makeit.bat).

Nor do you need to.  Nor should you.  In general, do not change any
options that we've set.

By the way, in previous versions of Comeau C++ under UNIX or LINUX,
if you wanted to install Comeau C++ to run in strict mode by default,
then you would have to install Comeau C++ in relaxed mode first,
then install libcomo, then reinstall Comeau C++ in strict mode.
However, Comeau C++ 4.3.2 and above for UNIX and LINUX supports a 
--no_a and --no_A command line option, which the libcomo UNIX
build uses by default.   So this is no longer a problem,
and libcomo can be built without the need to do anthing special
even if Comeau C++ is by default set up to run in strict mode.

Once libcomo is compiled, you can compile YOUR APPS using the
libcomo headers in strict mode (except on NetBSD which appears to be
provided with messed up system header files (it use to not be possible
on MS-Windows, but we have rectified that)).

There are lots of template instantiations, so be patient while
building libcomo.  Depending upon your OS, your disk space,
your RAM, etc., the compile could take just a few minutes, or,
it could take an hour or more.

Also, note that on some platforms some files will produce warnings.
To the best of our knowledge, all the warnings are safe.
In previous versions, you may have received a linker error when
building libcomo for Windows about 3 unresolved external symbols
_hypotf, _hypotl, and _main, but that should no longer occur
(it was the result of an extra link step, which now does not occur
since como.exe now supports a --prelink_objects option).
Under MS-Windows, check the file "makeout" for warnings and errors
after you build libcomo.

Note that the so-called "pure STL" part of libcomo is completely
header file oriented (for instance <vector>, but not <iostream>).
That means that if you don't use say the iostreams or string
part of libcomo, then you don't have to create libcomo.a/libcomo.lib,
nor even link with it.  Don't be too led astray though, as for
instance, std::string and iostreams have some actual lib requirements.

If you make any changes to the sources, please notify us about it.
That way, if we consider it generally useful, all users may benefit
when we post an update.

As with Comeau C++ itself, Comeau Computing is available to perform
custom ports of libcomo for you.  Contact us
with your particulars.

Some headers in the libcomo directory are provided as extensions.
That is, they are not part of Standard C++, nor is there any guarantee
that they may be added to Standard C++ at some future time (the C++
committee is currently (2006) still processing defect reports and although
it has also entered a formal revision status mode, the status of common
extensions won't be known for certain until it is completely commplete).
In any event, the following are generally useful extensions in libcomo:
hash_set, hash_map, hash_multiset, hash_multimap, hash, rope, and slist
classes.  Note that these extensions have not been fully tested with
Comeau C++ 4.2.45 or above.

libcomo is based upon SGI's Standard C++ Library.  Hundreds of code fixes,
enhancements, and compatibility improvements were made by Comeau Computing
for libcomo's use with Comeau C/C++, especially in Comeau C++
"strict mode".  Any changes made by Comeau to SGI's code follow
in the same spirit and words as HP and SGI's legalese.  In particular,
libcomo is released under the same terms as the SGI C++ I/O library,
and SGI's C++ I/O library is released under the same terms as the SGI STL. 


Copyright (c) 2000-2006
Comeau Computing

Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appears in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation. Comeau Computing makes no representations
about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty. 

Copyright (c) 1996-1999 
Silicon Graphics Computer Systems, Inc. 

Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appears in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation. Silicon Graphics makes no representations
about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty. 

Copyright (c) 1994 
Hewlett-Packard Company 

Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appears in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation. Hewlett-Packard Company makes no representations
about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty. 

       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
                       Producers of Comeau C/C++ 4.3.8
                   *** WEB: ***