and exception handling have a chance of working properly.
- creates libgcc, libgcc_eh and libgcc_s
- updates LIBGCC_SPEC to use them appropriately.
There's a hack in here at the moment with respect to libgcc_so in that it
is preferable to link against libgcc_so will only when -shared-libgcc is
specified (the c++ frontend does this automatically.) Configurations where
LINK_EH_SPEC is defined already do this. The gcc configuration for
NetBSD/alpha and another NetBSD platform (I forget which) actually define
LINK_EH_SPEC probably by accident rather than design.
- updates share/mk to use the compiler's knowledge of what needs linking into
libraries and executables. This removes an hppa hack.
- updates the sets for the newly created libgcc* files.
- support for linking against the _pg version of libgcc has been removed.
The benefits of having the symbol table available by default (easier
debugging of core dumps, etc) outweigh the minor (3%) increase in
the size of the distribution, and end-users can always strip(1) their
systems if they're concerned about that 3% of disk space.
This simplifies using ld with ${DESTDIR}/usr/lib whilst retaining the
(slightly faster) absolute links for the run-time libraries.
Per discussion on tech-toolchain.
(Side note; install(1) -l r needs the source to be prefixed with ${DESTDIR}
to operate correctly, which makes it non trivial to enable '-l r' by default
for all ${INSTALL_SYMLINK}s)
:M-[IDU]*
with
:C/-([IDU])[ ]*/-\1/Wg:M-[IDU]*
so that arguments with whitespace after them work correctly.
Resolves [toolchain/18248] from Andrew White at Motorola.
Be consisent in this syntax; previously we'd sometimes we'd just have :M-[ID]*
which would ignore -Ufoo ...
(This needs :C///W support in make(1) that Simon Gerraty added for me :)
Enable the in-tree toolchain on sh5, at least for the time being so I
can evaluate the situation.
There are still numerous problems with gcc3's sh5 support, not least
of which is the fact that a native gcc3 doesn't work at all. As a
cross-compiler, it works reasonably well. Certainly enough to build
userland and kernel code.
Binutils also has problems dealing with shared libraries on sh5, so
we're back to static userland for now.
