of BSS size. The conversion from a count of u8's to a count of
u32's was shifting in the wrong direction. This error had been in
the start code a long time. It had not caused problems because
the BSS is typically much smaller than the C heap which typically
follows it in memory. Plus since this code was executed at start
time, all that really happened was an extra zeroing of some memory.
I am not sure if this is related to this problem, but here is an observation:
All config.sub scripts from rtems' intrastructure packages internally
transform i386-rtems into i386-pc-rtems
newlib-1.8.0-rtems/config.sub i386-rtems --> i386-pc-rtems
egcs-1.0/config.sub i386-rtems ---> i386-pc-rtems
egcs-1.0.1/config.sub i386-rtems ---> i386-pc-rtems
bintutils-2.8.1.0.19/config.sub i386-rtems ---> i386-pc-rtems
gas-98xxxx/config.sub i386-rtems ---> i386-pc-rtems
The only exception is rtems itself:
rtems/config.sub i386-rtems ---> i386-rtems
I am not sure if this influences i386-rtems + c++/posix, but this indicates
that rtems' config.sub script should to be updated.
To fix this, simply copying config.sub e.g. from egcs and removing all
i[3456]-rtems* case statement lines from configure.in should be sufficient.
BTW, from autoconf's point of view i386-pc-rtems is the correct target
conforming autoconf's naming conventions, but using i386-rtems for all
packages (infrastructure and rtems) should make no difference.
It adds make rules for reconfiguring build-trees ("make Makefile") and
adds dependency rules for configure and friends (i.e. calls autoconf).
Most of this code has been "borrowed" from automake and was adapted to
rtems.
Addionally, I added automatic generation of the "aclocal.m4"-file by
"aclocal" (from the automake package). Therefore I splitted aclocal.m4
into several separate files (attached to this mail), each containing one
of rtems customized autoconf/m4-macros and have put them into a new
subdirectory "aclocal". Normal users won't be influenced and won't even
need this, unless they try to modify configure.in.
The main advantage of this is: these aclocal/m4-macros become reusable
and easier to administer. As a disadvantage, rtems becomes dependent of
having aclocal/automake installed. To keep building rtems functional if
autoconf or aclocal isn't installed, the related Makefile commands are
prefixed by "-" -- only an error message should be issued by "make".
Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working
with different shells and relative/absolute paths.
What I did is relatively simple in principle:
Instead of setting RTEMS_ROOT in configure.in and then let configure
substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile
set RTEMS_ROOT from each Makefile's @top_srcdir@ value.
The difference is subtile, but with enormous side effects:
- If RTEMS_ROOT is set in configure, then the same single value will be
propagated to all Makefiles. This breaks using relative paths, as the
relative path to the root of the source tree is used inside of all
subdirectory Makefiles.
- Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is
computed individually by configure for each single Makefile.in, hereby
receiving the correct value, no matter if relative or absolute paths are
used.
To get this working, I needed to remove setting RTEMS_ROOT from
target.cfg.in, because this overrides the value of RTEMS_ROOT from each
individual Makefile.
Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all
"include $(RTEMS_CUSTOM)" directives with"include
$(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this,
but I think, to have one variable less is clearer and easier to
understand than having several variables refering to the next one.
I enclose a small patch to this mail, which
- fixes the config.h problem (to finally clearify misunderstands)
- removes assignment/subsitution of RTEMS_ROOT from configure.in
- contains a workaround for the application Makefile's RTEMS_ROOT
problem (reported by Eric)
- removes some unused lines from the toplevel Makefile.in
- removes assignment of RTEMS_ROOT from make/target.cfg.in
> 4) The toplevel Makefile.in contains rules named make_subdir and
> clean_modules, which probably can be deleted, IMO.
> At least make_subdir doesn't give any sense anymore. (I had removed it
> im my original patch).
