$OpenBSD: README,v 1.7 1999/11/24 00:15:04 espie Exp $
Warning: highly experimental port.
It is assumed you know what you are doing by playing with this.
Some common problems:
- this port has no bison/yacc dependency. post-patch DOES fix the
timestamps so that the generated parser files are newer than the
corresponding yacc source. If this fails for you, blame your setup. *RUN*
a time protocol over NFS networks, heck, get a clue.
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.
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.
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.
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.
This is tied to weak symbol support.
--
Marc Espie
