mirror of
https://github.com/t-crest/rtems.git
synced 2025-11-16 12:34:47 +00:00
e81ef51bf1
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 (:-).
244 lines
7.9 KiB
Plaintext
244 lines
7.9 KiB
Plaintext
#
|
|
# $Id$
|
|
#
|
|
|
|
1. Autoconf support
|
|
===================
|
|
|
|
This version of RTEMS is configured with GNU autoconf. RTEMS can be
|
|
configured and built either standalone or together with the compiler
|
|
tools in the Cygnus one-tree structure. Using autoconf also means
|
|
that RTEMS now can be built in a separate build directory.
|
|
|
|
2. Installation
|
|
===============
|
|
|
|
2.1 Standalone build
|
|
|
|
To configure RTEMS for a specific target, run configure in the build
|
|
directory. In addition to the standard configure options, the following
|
|
RTEMS-specific option are supported:
|
|
|
|
--disable-rtems-inlines
|
|
--disable-posix
|
|
--disable-tests
|
|
--disable-ka9q
|
|
--enable-cxx
|
|
--enable-gcc28 (also use enable-libcdir when disabled)
|
|
--enable-gmake-print-directory
|
|
--enable-libcdir=<DIRECTORY> (do not use if gcc 2.8 is enabled)
|
|
--enable-rtemsbsp="bsp1 bsp2 ..."
|
|
|
|
In addition, the following standard autoconf options are frequently
|
|
used when configuring RTEMS installations:
|
|
|
|
--prefix=INSTALL_DIRECTORY
|
|
--program-prefix=
|
|
|
|
By default, the RTEMS posix interface is built for targets that support
|
|
it. It can be disabled with the --disable-posix option.
|
|
|
|
By default, the RTEMS port of the KA9Q TCP/IP stack is build for targets
|
|
that support it. It can be disabled with the --disable-ka9q option.
|
|
|
|
By default, the RTEMS support of C++ is disabled. It can be enabled
|
|
with the --enable-cxx option. If the rtems++ C++ library is installed
|
|
it will also be build.
|
|
|
|
By default, the RTEMS test suites are configured. The --disable-tests
|
|
will not configure the RTEMS test suite. This is used only to speed-up
|
|
configuration in case building the tests are not necessary.
|
|
|
|
By default, RTEMS is built using arguments and build rules which are
|
|
compatible with gcc 2.7.2.2. This requires that the user specify
|
|
the location of the Standard C Library with the --enable-libcdir
|
|
option. If using a gcc which supports the -specs option, then
|
|
the --enable-gcc28 option may be used to enable this feature.
|
|
You should use the --enable-gcc28 option when using either the
|
|
egcs source tree, testgcc snapshots, or gcc 2.8.0 or newer.
|
|
|
|
By default, all bsps for a target are built. There are two ways of
|
|
changing this:
|
|
|
|
+ use the --enable-rtemsbsp otion which will set the specified
|
|
bsps as the default bsps, or
|
|
+ set the RTEMS_BSP variable during make (see below).
|
|
|
|
The --enable-rtemsbsp= option configures RTEMS for a specific target
|
|
architecture. The following targets are supported:
|
|
|
|
(none) will build the host-based version on Linux,
|
|
Solaris and HPUX.
|
|
|
|
a29k-rtems only standalone, uses non-gnu compiler
|
|
i386-rtems
|
|
i386-go32-rtems see notes
|
|
i960-rtems
|
|
hppa1_1-rtems
|
|
m68k-rtems
|
|
mips64orion-rtems
|
|
no_cpu-rtems
|
|
powerpc-rtems
|
|
sparc-rtems
|
|
|
|
The cross-compiler is set to $(target)-gcc by default. This can be
|
|
overriden by:
|
|
|
|
+ using the --program-prefix option to configure to specify the
|
|
string which will prepended to the tool names. Be sure to include
|
|
a trailing "-". For example, to use a m68k-coff toolset, use the
|
|
--program-prefix=m68k-coff- option.
|
|
|
|
To build, run make in the build directory. To specify which bsps to build,
|
|
add the RTEMS_BSP="bsp1 bsp2 .." to the make command. Specifying multiple
|
|
BSPs to build only works from the top level build directory.
|
|
|
|
Installation is done under $(prefix)/rtems.
|
|
|
|
As an example, to build and install the mvme136 and dmv152 bsps for m68k do:
|
|
|
|
(path_to_rtems_src)/configure --target=m68k-rtems
|
|
|
|
make RTEMS_BSP="mvme136 dmv152"
|
|
|
|
make install RTEMS_BSP="mvme136 dmv152"
|
|
|
|
The sample tests are built by 'make all', do a 'make test' to build the full
|
|
test suite.
|
|
|
|
2.2 Build with Cygnus one-tree release
|
|
|
|
To build and install RTEMS with the one-tree structure, just copy the rtems
|
|
directory to the tree. The one-tree configure.in and Makefile.in has to be
|
|
replaced with the RTEMS-aware versions. The build options are the same as
|
|
for the standalone build.
|
|
|
|
2.3 Target Dependent Notes
|
|
|
|
i386-go32-rtems:
|
|
|
|
1. This is based on djgpp v1.xx. It needs to be updated to v2.xx.
|
|
2. This cannot be built one-tree style since RTEMS requires some
|
|
files which must be obtained from the binary distribution of the
|
|
djgpp library. DJGPP can be obtained from
|
|
http://www.delorie.com/djgpp/dl/ofc.
|
|
3. You will need to manually install a number of files from the
|
|
binary distribution of the DJGPP library doing something
|
|
like the following:
|
|
|
|
# unzip the djgpp distribution
|
|
cd include
|
|
cp dpmi.h INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/include
|
|
cp go32.h INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/include
|
|
cp dos.h INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/include
|
|
cp pc.h INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/include
|
|
|
|
cd ../lib
|
|
cp crt* INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2
|
|
cp libpc* INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2
|
|
|
|
# Make sure about destination on the next lines. It keeps the newlib
|
|
# libc.a and the binary djgpp libc.a from conflicting.
|
|
cp libc.a INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/libcgo32.a
|
|
cp libc_p.a INSTALL_POINT/lib/gcc-lib/i386-go32-rtems/2.7.2/libcgo32_p.a
|
|
|
|
|
|
3. To use the installed RTEMS library
|
|
=====================================
|
|
|
|
To use the installed RTEMS bsps to build applications, the application
|
|
makefile has to include a bsp-specific makefile that will define the
|
|
RTEMS variables necessary to find include files and libraries. The
|
|
bsp-specific makefile is installed at
|
|
|
|
$(RTEMS_MAKEFILE_PATH)/Makefile.inc
|
|
|
|
For the erc32 bsp installed at /usr/local/cross, the environment
|
|
variable RTEMS_MAKEFILE_PATH would be set as follows to the
|
|
following:
|
|
|
|
/usr/local/cross/sparc-rtems/rtems/erc32/Makefile.inc
|
|
|
|
4. Supported target bsps
|
|
========================
|
|
|
|
The following bsps are supported:
|
|
|
|
host-based : posix (on linux, solaris and hpux)
|
|
|
|
a29k : portsw
|
|
i386 : force386 i386ex
|
|
i386-go32 : go32 go32_p5
|
|
i960 : cvme961
|
|
hppa1_1 : simhppa
|
|
m68k : dmv152 efi332 efi68k gen68302 gen68360 gen68360_040 idp
|
|
mvme136 mvme147 mvme147s mvme162 ods68302
|
|
no_cpu : no_bsp
|
|
mips64orion : p4600 p4650 (p4000 port with either R4600 or R4650)
|
|
powerpc : papyrus
|
|
sparc : erc32
|
|
|
|
5. Makefile structure
|
|
=====================
|
|
|
|
The makefiles have been re-organised. Most gnu-based bsps now use three
|
|
main makefiles:
|
|
+ custom/default.cfg,
|
|
+ custom/bsp.cfg and
|
|
+ ompilers/gcc-target-default.cfg.
|
|
|
|
Default.cfg sets the deafult values of certain common build options.
|
|
|
|
Bsp.cfg set bsp-specific build options and can also override the
|
|
default settings.
|
|
|
|
Gcc-target-default.cfg contains the common gcc definitions. Some targets
|
|
(a29k, no_cpu, and posix) still use the old structure.
|
|
|
|
6. Adding a bsp
|
|
===============
|
|
|
|
The top-level configure.in has to be modified if a new target is added
|
|
or if a new bsp is to be built by default. The additions required is
|
|
basically to add which makefiles are to be created by configure and
|
|
to add the target to the selection statement. To re-generate
|
|
configure, autoconf-2.12 is needed.
|
|
|
|
7. Tested configurations
|
|
========================
|
|
|
|
All gnu-based bsps have been built on Linux.
|
|
The native (posix) ports have been built and run only on Linux.
|
|
|
|
The following configurations have NOT been tested:
|
|
|
|
+ Anything on Nextstep, HPUX and Irix.
|
|
+ The a29k port.
|
|
|
|
8. Pre-requisites
|
|
=================
|
|
|
|
Gawk version 2 or higher.
|
|
GNU make version 3.72 or higher.
|
|
Bash.
|
|
gcc version ???
|
|
|
|
TODO
|
|
====
|
|
|
|
The install-if-change script requires bash. On solaris systems, this should
|
|
be changed to ksh, since ksh is provided with solaris (bash not).
|
|
|
|
A fairly rescent version of gawk is needed to build RTEMS. This should be
|
|
changed so that a plain vanilla awk also works. [NOTE: This dependency
|
|
should disappear when the "gcc 2.8 -specs" is finished.]
|
|
|
|
'make install' should only install necessary files, not the full
|
|
PROJECT_RELEASE directory as now.
|
|
|
|
Posix port on solaris-2.5 fails due to undefined built-in functions
|
|
(gcc-2.7.2, might be my installation).
|
|
|
|
Improve support for 'make CFLAGS=xxx'.
|
|
|