"Ladies and Gentlement, we proudly present: a roughly hacked autoconf-ed
rtems-glom.in" (:-)
BTW, to follow up to the discussion about installation points, rtems-glom in
its current shape is an ideal example of a target dependent file. If
bsp-specific configure-scripts would exist, it might also be a bsp-dependent
file that contains RTEMS_BSP hard-coded (by configure) into it.
I've gone through and cleaned up the TFTP driver so that it fits
into the libio system. Here's the comment from the new driver:
/*
* Usage:
*
* To open `/bootfiles/image' on `hostname' for reading:
* fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY);
*
* The `hostname' can be a symbolic name or four
* dot-separated decimal values.
*
* To open a file on the host which supplied the BOOTP
* information just leave the `hostname' part empty:
* fd = open ("/TFTP//bootfiles/image", O_RDONLY);
*
*/
You can `fopen' TFTP files the same way:
fp = fopen (fullname, "r");
nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp);
The diff's are included below. I've also modified the TFTP demo
program and the bootstrap PROM example. They should be on my ftp
site `soon'.
The one thing I don't like is the way I had to do an end-run on the
libio routines to get errno passed back from my driver to the
application (since there are some errno codes that don't map to RTEMS
status codes). My approach was to set errno in the driver and have
the driver routine return an RTEMS status code that I `know' isn't in
the errno_assoc[] in libio.c.
Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or
something similar) which driver routines could return to indicate
that the driver routine has set errno and that the libio routines
shouldn't attempt to map the returned status code to errno.
Actually, I think the entire I/O system needs looking at -- as
you've already mentioned. The hacks I've dropped in to syscalls.c to
make fstat work, for example, are *not* shining examples of good
code......
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.
IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
esac],[RTEMS_USE_GCC272=yes])
3) At the end of c/src/exec/score/cpu/m68k/m68k.h
> #ifdef __cplusplus
> }
> #endif
>
> #endif /* !ASM */
in my opinion these two statements should be swapped:
> #endif /* !ASM */
>
> #ifdef __cplusplus
> }
> #endif
I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.
Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.
I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.
Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.
Peanuts sofar, ... but here it comes ... (:-)
8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.
Motivation:
* Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
* Fix -pipe problems
* Fix problems with hard-coded paths in configuration files (esp. posix)
* Fix consistency problems with explictly given gnutools and gcc's gnutools
Currently included:
* detection and checking of host and target compiler (gcc/g++)
* checking if target gnutools are in path
* checking if <target>-gcc -specs works (autodisabling gcc28 if not)
* checking if <target>-gcc -pipe works
Todo :
* *posix.cfg files are not yet adapted => The hard-coded paths for these
systems are still in use.
* Check if the host compiler $CC is properly propagated to the Makefiles (I
doubt it, but this should not matter)
* Check if rtems' generic tools still work properly (It looks like, but who
knows)
* Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks
like C++ support is only used by posix BSPs)
* Automatically handle RANLIB/MKLIB for targets
* Plenty ... (:-)
Open problems:
* Untested for non-gcc compatible host and target compilers. This should be
no problem if the tools are named follow gnutool's naming convention and are
included in $PATH while running configure.
* Intentionally using different tools than that gcc has been configured for,
e.g. use a different assembler ? This should be still possible if
XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody
should want to do this, but who knows?
I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).
I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).
I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.
IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
esac],[RTEMS_USE_GCC272=yes])
3) At the end of c/src/exec/score/cpu/m68k/m68k.h
> #ifdef __cplusplus
> }
> #endif
>
> #endif /* !ASM */
in my opinion these two statements should be swapped:
> #endif /* !ASM */
>
> #ifdef __cplusplus
> }
> #endif
I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.
Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.
I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.
Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.
Peanuts sofar, ... but here it comes ... (:-)
8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.
Motivation:
* Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
* Fix -pipe problems
* Fix problems with hard-coded paths in configuration files (esp. posix)
* Fix consistency problems with explictly given gnutools and gcc's gnutools
Currently included:
* detection and checking of host and target compiler (gcc/g++)
* checking if target gnutools are in path
* checking if <target>-gcc -specs works (autodisabling gcc28 if not)
* checking if <target>-gcc -pipe works
Todo :
* *posix.cfg files are not yet adapted => The hard-coded paths for these
systems are still in use.
* Check if the host compiler $CC is properly propagated to the Makefiles (I
doubt it, but this should not matter)
* Check if rtems' generic tools still work properly (It looks like, but who
knows)
* Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks
like C++ support is only used by posix BSPs)
* Automatically handle RANLIB/MKLIB for targets
* Plenty ... (:-)
Open problems:
* Untested for non-gcc compatible host and target compilers. This should be
no problem if the tools are named follow gnutool's naming convention and are
included in $PATH while running configure.
* Intentionally using different tools than that gcc has been configured for,
e.g. use a different assembler ? This should be still possible if
XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody
should want to do this, but who knows?
I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).
I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).
I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
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".
