107 lines
4.7 KiB
Plaintext
107 lines
4.7 KiB
Plaintext
$OpenBSD: README,v 1.6 1999/02/23 09:28:23 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.
|
|
|
|
|
|
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.
|
|
|
|
[ As of 19990221, the i386,m68k,sparc,alpha flavors of OpenBSD are now
|
|
officially supported by egcs. I have hopes for the 1.1.2 release. ]
|
|
|
|
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. Other arches are well along the way...
|
|
|
|
As of 19990131, I checked that i386 and m68k did work.
|
|
I don't recommend 19990208 for production use. There are fairly recent
|
|
changes to the loop handling code that breaks useful stuff, such as
|
|
gnu-grep...
|
|
|
|
As of 19990214, the newer loop code is deactivated. I've been working on
|
|
sending precise bug reports to solve most of the bugs.
|
|
|
|
19990221 is the first snapshot to include support for
|
|
i386,m68,sparc,alpha-openbsd out of the box.
|
|
|
|
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
|