	Sun3 SunOS 4.0: ld++ cannot find Mcrt0.o:

	Turns out that gcc.c as distributed allows you to redefine
	STANDARD_STARTFILE_PREFIX to be any directory you want.  It
	will check there and in /usr/local/lib 	for startup files, not
	in /usr/lib.  Unfortunately, most system startup files live in
	/usr/lib, so unless you define STANDARD_STARTFILE_PREFIX to be
	/usr/lib, you'll lose.  I changed the line in gcc.c

	char *standard_startfile_prefix_1 = "/usr/local/lib/";

	to read 

	char *standard_startfile_prefix_1 = "/usr/lib/";

	This way I can specify my own startfile directory, without
	losing access to the system startup files.

						Moises

-----------------------------------------------------------------------------
Internet/CSnet:   mlm@cs.brown.edu		BITNET:  mlm@browncs.BITNET
UUCP:    ...!uunet!brunix!mlm			Phone:	 (401)863-7664
USmail:  Moises Lejter, Box 1910 Brown University, Providence RI 02912

	If you are using a non-Sun machine, and use the native
	assembler instead of GAS, you will need to #define FASCIST_ASSEMBLER
	when compiling cplus-decl.c.  This is because Sun's as and GAS
	appear to be the only assemblers out there which assemble stabs
	instead of checking them.  If you don't remember to do
	this, the assembler will remind you by telling you that it did
	not understand a stab which the compiler is trying to pass to
	the linker.

Michael Tiemann
tiemann@lurch.stanford.edu

----------------------------------------------------------------
The 2.0 C++ language specification provides many new features which
can trip up the novice user.  All of these features are being
implemented in GNU C++, and most of them work right now.  However,
this does not mean that they are all that easily used.  Perhaps on of
the toughest new features to take advantage of right now is extern "C".
What makes this hard is that up until now, C and C++ really looked
like they had about the same langauge linkage.  Member functions had
their names mangled, but non-overloaded global functions did not.
In 2.0, all functions declared in C++ scope are automatically
overloaded, and all such functions all get mangled names.  So if you
declare, e.g., `int printf (const char *, ...)' in C++ language scope,
and you get printf from libc.a, you will lose, since the compiler will
assume that you are looking for e.g., "_printf_PQI", when you are
really looking for "_printf".  To get around this problem, you can use
extern "C" to tell the compiler which names should be mangled and how.
There is a macro called NO_AUTO_OVERLOAD, which if defined, will provide
the standard cfront 1.2 and old GNU C++ behavior.  If not defined, it
provides the cfront 2.0 behavior.  One should move from the old to the
new carefully, and if you get lots of new undefined symbols from the
linker where such did not exist before, the first question you should
ask yourself is `how is extern "C" or extern "C++" doing me in?'

Michael Tiemann
tiemann@lurch.stanford.edu
----------------------------------------------------------------
There is a bug in the GNU CC 1.35 optimizer.  Currently, this shows up
only when compiling libg++/src/BitString.cc and libg++/tests/tBitString.cc
If you get failed assertions in the bitfield code, you have been
bitten by this bug, and you should turn off optimization.
Optimization does work for all the OOPS code, and for all other libg++
code, so you probably don't want to turn it off unless you need to run
BitString code.

Michael Tiemann
tiemann@lurch.stanford.edu
----------------------------------------------------------------
