I get the following warning when compiling the latest snapshot. I had
a quick look at the source -- it certainly looks to me like this is a
real bug.
../../../../src/rtems-19990709/c/src/lib/libc/mount.c:97: warning:
`options' might be used uninitialized in this function
Also, I changed the TFTP test program and TFTP driver to reflect the
changes in the way paths are passed to the TFTP driver. The TFTP driver
now needs a proper `dotted-decimal' hostname as the second component of
the path name.
- The same bug fix that was done on pc386 to prevent interrupt
from occuring (never experienced it but who knows as I have 8259
emulation :()
- Removed every compiler warning (except wrong ones and ones I can't do
anything).
- Removed any libc available code in code linked with mcp750 rtems
executbale. Unfortunately using newlib functions for linking the
bootloader does not work as the compilation options in bootloader
(-mrelocatable -fixed-r13) are not compatible with newlib options.
=> I have put any libc external reference in one single new file (lib.c)
that is linked only with the boot loader. Removing the file from
${OBJ} and using -lc crash the bootloader. Added big warning...
boot_card() and main() into separate files to ease configuration
of other packages. This was a big step in the way to build TCL,
ncurses, and zlib for RTEMS.
-- configure now fails to detect the toolchain for linux-posix.
As work-around, I have reverted to the old behavior of RTEMS_TARGET_CPU_NAME,
thus no_cpu/no_bsp will fail badly in configure again.
> When I run my script that just repeatedly builds different targets, some
> of them die with an error like this:
>
> Making all RTEMS_BSP=gen68360 in cpugmake[5]: Entering directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
> Making all RTEMS_BSP=gen68360 in @RTEMS_CPU@
> /bin/sh: @RTEMS_CPU@: No such file or directory
> gmake[5]: *** [all] Error 1
> gmake[5]: Leaving directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
>
> It is not always the same variable substitution that fails. Sometimes it
> is @INSTALL@. But reliably, it is a variable substitution that is
> failing.
>
> Do you have any idea why this happens?
Yep, I think I know what's going on.
AC_SUBST(RTEMS_CPU) is missing in configure.ins, thus @RTEMS_CPU@ in
target.cfg.in doesn't get substituted correctly, causing the bug above. Due
to the redundancy of RTEMS_CPU, other most BSPs don't seem to be affected.
Other similar problems probably exist for the unix/posix bsp and the hppa.1
cpu, because their */tools/*Makefile.ams require RTEMS_CPU, too.
