The patch contains:
* build variants support
* Reworked make-exe custom/*.cfg for all targets (Should be
self-explanatory, may still be incomplete)
* Several fixes to custom/*.cfgs related to setting debug flags
* Fixes to some bsp_specs for BSPs which apparently have never been
build with debugging before ;)
* pc386.cfg fix attempts (cf. my mail from earlier today)
* Updated ampolish (No need to run it, the patch contains the result
from having applied it)
Known bugs/deficiencies related to this work:
* "make [clean|distclean]" support is still incomplete (e.g. "make
clean" does not delete all Depends-o-*)
* Completely untested for linux/posix and hppa.
* Build failures of i960 BSPs (make VARIANT=DEBUG) - I guess, they are
not related to this patch.
* Successfully tested for all sh, sparc, i386, ppc, m68k BSPs (make
VARIANT=DEBUG)
* make VARIANT=PROFILE not supported by all BSPs (I don't care :)
* make VARIANT=DEBUG failures below tests/ for some BSPs (e.g. gensh1),
because of the tests's binaries being too large to fit into the target
memory layout.
that contains:
* Removes remaining (now illegal) references to $(SRC) from a couple of
Makefile.ams
* Removes duplicate AC_CONFIG_SUBDIRS macro from c/configure.in
* Moves ENABLE_LIBCDIR into RTEMS_PROG_C[C|XX]_FOR_TARGET (hides LIBCDIR
from most configure scripts, i.e. LIBCDIR becomes less visible)
* Adds RTEMS_PROG_C[C|XX]_FOR_TARGET and RTEMS_CANONICALIZE_TOOLS to
libbsp/*/configure.ins (A minor bug in previous implementations, which
only has an impact when switching to GNU/Cygnus canonicalization)
* Cleans up several bogus comments.
* Removes MKLIB
* Switches the version number to 4.5.0 (for testing version number
handling)
* the PACKHEX etc problem
* prevents the *.rels being removed inside the build-tree
* a typo which only shows for when MP is activated
* Alters some custom/*cfg files
<corsepiu@faw.uni-ulm.de> which does the following:
This is the configuration cleanup patch:
Main changes:
* TARGET_ARCH removed
* target.cfg.in moved to c/make/target.cfg.in (Only configured once for
all BSPs of a target)
* BARE_XXX variables appended to bsp.cfg.in
* autogen renamed to bootstrap
* removed stray variables from make/custom/*.cfg
To apply:
cd <source-tree>
rm c/src/make/target.cfg.in
cp autogen bootstrap
mkdir c/make
cp make/target.cfg.in c/make/target.cfg.in
rm make/target.cfg.in
rm autogen
patch -p1 < rtems-rc-19991105-1.diff
Here's a patch to get rid of the `#define RTEMS__mcpu32p__ 1' when
gen68360.cfg is being used as a companion for gen68360_040.cfg. The
old version worked because of the order of the conditional tests in
m68k.h (the check for __mc68040__ is before the test for
RTEMS__mcpu32p__) , but I think it might have been a little confusing
to others just getting started.
I found that my 68040/68360 test programs would not run even after
I fixed the `wrong BSP' problem.
It seems that there's a bug in the interrupt handling code for
processors with hardware interrupt stacks (e.g. 68040). The wrong
status register was getting pushed on the stack for the `return
from exception' to call _ISR__Dispatch. This ended up making
the context switch code run on the interrupt stack, so interrupt-driven
context switches would always fail.
I guess that no one has tried running any of the RTEMS-4.0 snapshots
on a 68040 machine!
Anyhow, here are the patches for
1) gen68360.cfg --- to fix the `wrong-BSP' problem.
2) m68k/cpu_asm.s --- to fix the hardware interrupt stack problem.
With these patches in place, the network demo programs run on my
68040/68360 system. The paranoia program runs with no failures,
defects nor flaws.
made no attempt to divide the comments up and place them with just
the appropriate files. Here is an excerpt from Ralf's email:
Changes including comments on changes I made after cycling through
all the targets:
* Added ranlib support. Now all targets use "ranlib" instead of "ar -s"
to build an index for a library. If ranlib isn't detected during
configuration, check if ar -s is working and try "ar -s" instead of
* Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now.
* gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l
problem under posix (cf gcc-target-default.cfg)
* rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in
that has been using rtems-glom until now.
* Removed CCC and friends in gcc-target-default.cfg, as they have been
breaking CXX support.
* Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg
files, because this is now set in custom/default.cfg.
* Added aclocal/ar-s.m4, check whether "ar -s" is working
* Added aclocal/cygwin.m4 and aclocal/exeext.m4.
* Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for
problems when XXX_FOR_TARGET is given via environment variables (didn't
work for gcc until now), adding cygwin check, improved autoconf-cache
handling.
* Removed -l from make rule dependencies. LINK_LIBS is now allowed to
contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l.
gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost
all custom/*.cfg are modified. This is very likely to break something
because of typos or having missed to edit a file.
Open problems, known bugs, things I didn't do:
* custom/p4000.cfg seems to be out of date and requires to be reviewed.
(JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok
after minor changes.)
* custom/psim.cfg needs to be reviewed, I added some changes to it, I am
insecure about.
(JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.)
* rtems-glom.in can now be removed.
* gcc*.cfg files "make depend" rules don't honor language specific flags
(e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may
cause problems for hosts/targets not using gcc or rtems-add-ons that use
external packages.
* AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused
to configure for it whatever I tried.
* The toplevel and toplevel+1 README files are quite out-dated
* cygwin.m4 isn't of much use for rtems. In most cases (cf.
aclocal/*.m4) it is worked around by directly using $host_os. I think
I'll remove it soon after the next snapshot
* Before release the cygwin patch needs to be tested under cygwin. I may
have broken/missed something (esp. the sed-pattern to convert \\ into /
may be broken).
* You should try to build/run the posix-BSP under solaris - I don't
expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s.
* You should consider to convert all make/compilers/*.cfg files into
make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This
may help getting rid of some if/then/else statements and help
hard-coding some defines into those files in future and shouldn't
disturb now.
* Not having installed libc.a/libm.a on a host may still break building
rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme
directly accesses libc.a and libm.a. The problem should not appear when
using gcc28 because it references libc/libm only through -lc and -lm
which may be static or dynamic (I didn't test this).
* shgen is not yet included (I didn't yet have enough time to integrate it).
* I know about a few more configure-probs (esp. cross-checking
--enable-* flags).
+ warn/refuse to configure when --enable-libcdir and
--enable-gcc28 are given.
+ force --enable-libcdir when --disable-gcc28 is given
* Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in.
* Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure
and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed
* Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4
* Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.*
in configure.in, as I suppose there might exist a variety of valid vendors
(2nd field of the name-tripple)
* Disabled override MAKEFLAGS in toplevel Makefile.in - Potential
side-effects are not really clear to me.
* In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe
rule (yet another one I missed to edit). Just append $(LINK_LIBS) to
the "CC" line, like I hopefully did to ALL other custom/*.cfg files.
* the problem with mvme162lx.cfg is a follow-up problem of the
mvme162.cfg-bug.
* mvme162/console and idp/console had variables named Buffer which
conflicted with similarly named variables in some tests.
Here are some patches to the gen68360 BSP. The improvements include:
Boot prom run-time selection of DRAM size (1/4/16 Mbytes)
Full 32-bit ethernet address obtained from boot prom.
Updated README.
I've included a version of make/custom/gen68360.cfg that works with
this. Note that I've removed the option of using `-m68020
-msoft-float -mno-bitfield' as an alternative to using `-mcpu32'.
The alternative won't work with the new system (since it predefines
__mc68020__ and not __mcpu32__), and didn't really work before anyway
(since the newlib that gets linked was built with `-m68020
-msoft-float' and so could contain bitfield operators).
While trying to work through this problem I decided that the
build-time selection of the console I/O operation (polling or
interrupt) was too clumsy. Here's a patch that allows run-time
(actually init-time) selection of the console I/O mode.
It also shows the need for another `flags' or `options' field in
the rtems_driver_address_table structure...
