openbsd-ports/lang/egcs/snapshot/README

$OpenBSD: README,v 1.4 1999/02/03 18:02:53 espie Exp $

Warning: highly experimental port.

It is assumed you know what you are doing by playing with this.

I am currently rewriting the openbsd configuration files, mostly from
scratch, in order to clean them up.  Goal is to have something I can
file up with the FSF as soon as possible, so that egcs 1.1.2 will have
*official* openbsd support.

There are copyright issues involved.

If configuration for your favorite processor does not work, there are
two possibilities:

- you can send me complete bug reports, telling me what's wrong, and I will
try to get a viable configuration.
- you can do it yourself but, for any non-trivial change, you *MUST* file
a copyright assignment with the FSF. Otherwise, your patch won't make it
to the official egcs distribution, and we all lose.

One point of the clean-up is to be able to trace the configuration
precisely, so that it becomes easier to track newer versions of egcs,
or port OpenBSD to other architectures. Accordingly, each code fragment
has to be tagged with the place it originally came from, and variations
from standard practice have to be thoroughly documented.

For instance, if you have to change CC1_SPEC for OpenBSD, it is important
to know what you changed from that default processor configuration: when
egcs evolves and add new specs, it's easier to know what to pick up, and
what to leave alone.

As another example, netbsd recently added '.globl' to ASM_WEAKEN_LABEL,
and it took me a while to figure it out. Apparently, this is something that
is required for arm32 to work. No reason it should contaminate other
architectures as it did.

As a final example, it turns out that a large part of openbsd configuration
information in gcc 2.8.1 was just random cut&paste which didn't make much
sense in many cases... Ultimately, I hope that all egcs/gcc openbsd flavors
will use the same configuration files.

From a technical point of view, part of the challenge is that some bugs
may come from the compiler, some from the assembler, and from the linker.
It's likely that the only way to resolve many bugs will be to finally 
upgrade to a recent binutils... For instance, C++ currently has to resort
to substandard setjump/longjump exceptions as we don't handle dwarf2 unwind
info correctly.

Accordingly, if you use this port, you MUST track current. For instance,
Jason recently fixed a bug in gas that showed up during sparc bootstrap.

Please read the Makefile before attempting to build this port. There might
be some tweaks involved. Start with make patch, then read the
documentation, and decide on changes. For instance, C++ folks may wish to 
play with -fsquangle: since this is an option you need to activate for
building the library, you had better decide from the start.

On the other hand, there are several known situations which confuse our
specific flavor of gas. For instance, some recent snapshots built fine on the
older machines with default CFLAGS (-O2 -g), but crash when -g is removed.
This seems to be fixed as of 19990131

As of 19990117, I personally built egcs for m68k, i386, alpha, and sparc.
So all those archs *do* work. If it doesn't work for you, you've been doing
something wrong.

As of 19990131, I checked that i386 and m68k did work.

Once you get through all those caveats, and manage to build egcs, one
nice point is that you get fairly good C, C++, f77, objective-C, and
java compilers.

Thread support
--------------
I'm currently building on d's work with respect to libc_r... I've added
some provisions for adding -pthread everywhere it's currently needed.

Test support needs the same -pthread, e.g., you'll probably have to edit
/usr/local/share/dejagnu/baseboards/unix.exp to add
set_board_info cflags	"-pthread"
I haven't yet modified the testsuite framework for that. I'm somewhat
hoping we'll find a less kludgy solution than -pthread to activate libc_r.

--
	Marc Espie