f844940867
So, here goes. - retrieve a recent snapshot of egcs, to justify the port's existence, - remove outdated fixes, now that we're synching with 2.6, - update patches to deal with the current snapshot, - get a description that matches better what's going on, - add fixed include files to match the new varargs handling (complexity is now within gcc, instead of arch-dependent include files). Builds on i386, at least.
64 lines
2.8 KiB
Plaintext
64 lines
2.8 KiB
Plaintext
$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
|