the rules how to build those sources. Generate makefiles defining ${COPTS},
${CPPFLAGS}, and ${SRCS} (== template).
Note that ${CPPFLAGS} is actually dfined as _CPPFLAGS like
_CPPFLAGS.tmp___gcc_bcmp.c=-DL__gcc_bcmp
and used to generate wrapper files (e.g. tmp___gcc_bcmp.c). Otherwise it's
automagically passed to ${CC} by bsd.*.mk.
We create wrapper sources (tmp_*.[cS]) on-the-fly and compile them. For
example, __gcc_bcmp() is compiled using tmp___gcc_bcmp.c, which #define's
L__gcc_bcmp and #include's libgcc2.c.
repeatedly with different -DXXX to generate similar objects (e.g. different
type size).
- Generate a list of other CC options to build *.o.
(See my sed-fu using hold space in get_libgcc_list_objs_xflags().)
parsing dependency lines in libgcc.mk.
- Generate a list of *.o -> *.{c,S} mapping. *.S files are known as
${LIB1ASMFUNCS}. Assume other *.o files are built from *.c. This information
is needed to generated wrapper sources later.
BSD makefiles to build libgcc. The goal is to build all functions rather
than managing the set of functions in gnu/lib/libgcc/Makefile.in by hand.
Because of the complexity of the build procedure, I leave not only generated
makefiles but also intermediate, analyzed data so that people can verify that
the conversion is done correctly.
makes {MK,HAVE_}BINUTILS consistent with {MK,HAVE_}{GCC,GDB}.
Allow MKBFD to defines MKBINUTILS as a backwards compatibility hook.
Update the sets lists and add conditionals for lib{bfd,opcodes}.
both CONFIGURE_ARGS and NATIVE_CONFIGURE_ARGS to reduce duplication
between tool and native configuration
-allow to pass a "--with-arch" argument to both configurations
Where sed is used in a != assignment, use
.if make(depend) || make(all) || make(dependall) || make(install)
to ensure the command doesn't run at "make obj" time when TOOL_SED will
not have been built.
libgcc/multilib on amd64
- enable the 32/64 bit libgcc/multilib support on sparc64
- adapt mknative-gcc to grab multilib.h
- use --enable-multilib on amd64 and sparc64
none of this affects the installed tools yet, just the src/tools one.
(for booth the tool build and mknative). gcc's "config.gcc" sets
it if the target is netbsd[2-9], but since the target is w/o version
number in our builds, it has no effect. Found by Nick Hudson,
patch approved by mrg.
has ssp functions built-in" test via the TARGET_LIBC_PROVIDES_SSP environment
variable, to allow us to configure a cross-compiler appropriately without
having to try to find out by looking in the target's source directory.
Tweak our build to tell gcc that the ssp bits are now in libc.
The native compiler appears to already think that the ssp bits
live in libc, so no change appears to be needed there.
The autoconf-generated configure script will be committed separately shortly.
flag. This ensures that -j<N> isn't accidentally inherited from the
environment, because the "--- foo ---" headers printed with -j<N> would
interfere with parsing the output.
- get the information from a gcc3 .native
- don't get gcc4 variables
- put back the getvars for SHLIB_LINK SHLIB_MULTILIB as they work
on gcc3 and leave as XXX'd on gcc4.
I've re-arranged some of the variables to minimise the differences, but
didn't do them all.
- look in gnu/dist/gcc4
- don't build fortran
- use /usr/bin/env -i so that gmake works (XXX - breaks from MAKEFLAGS
in the build.sh generated makewrapper.)
- use gmake and Makefile.gmakehost
- update .native/.configure_done target
so generated objects vs listed objects in make line up and dependcies happen
correctly. Found because libiberty (on this binutils import) was leaving
all objects as ./object.o and make wasn't picking up correct depends on
config.h as a result.
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.
- Disable symbol versioning (for now)
- Make sure that libiberty knows its being configured with a
cross compiler.
- The CXX_* variables are no longer needed/used.
- LIB2FUNCS_EXTRA gets pulled in via LIB2ADD
- Get LIB1ASMFUNCS and LIB2ASMSRC
- MAYBE_USE_COLLECT2 got renamed to USE_COLLECT2 (but might not
be used)
- Get EXTRA_HEADERS so that we get generate the right paths for
CPPFLAGS
- Get some variables related to shared libgcc
the tool build from attempting to build the GCC crtstuff before the
target include files are installed. PR toolchain/23112.
(Note: You would not see the bad behavior described in the PR unless
your .mk files were hacked to configure the toolchain target as
*-*-netbsd*2.0.)
uebayasi