The patch below actuallly consists of two patches:
1) moving librpc to c/src/librpc similar to what has been done to librtems++
2) reworked configure scripts, many safety and dependency checks added to
aclocal/*.m4 macros + configuration fixes.
To apply:
mkdir c/src/librpc
mkdir c/src/librpc/src
cp c/src/lib/librpc/*.c c/src/librpc/src
cp c/src/lib/librpc/Makefile.in c/src/librpc/src
mkdir c/src/librpc/include
mkdir c/src/librpc/include/rpc
cp c/src/lib/include/rpc/* c/src/librpc/include/rpc
patch -p1 < ../rtems-rc-19990820-7.diff
rm -rf c/src/lib/librpc
rm -rf c/src/lib/include/rpc
./autogen
The additional checks in aclocal/*m4 macros add rather restrictive, sometimes
unnecessarily restrictive constraints on the sequence of how macros can be
used in a configure.in script. Adding them has let my problems with some more
complicated configuration options vanish. Apparently some macros had not been
in the required order .
----
Now I still get some linking errors for some cpus and bsps, esp when linking
cdtest, but also at other locations:
e.g. this happens for mips64orion/p4600:
# make[5]: Entering directory
`/lfs/poseidon/users/rtems/src/multi/build/mips64orion-rtems/c/p4600/tests/samples/hello'
/opt/rtems/bin/mips64orion-rtems-gcc --pipe -B../../../../../../p4600/lib/
-specs bsp_specs -qrtems -DP4000 -DCPU_R4000 -DP3_DIAG -D_R4000 -D__mips=3
-mcpu=4600 -G0 -I../../../../../../p4600/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -o o-p4600/hello.exe
o-p4600/init.o ../../../../../../p4600/lib/no-dpmem.rel
../../../../../../p4600/lib/no-event.rel
../../../../../../p4600/lib/no-msg.rel ../../../../../../p4600/lib/no-mp.rel
../../../../../../p4600/lib/no-part.rel
../../../../../../p4600/lib/no-signal.rel
../../../../../../p4600/lib/no-timer.rel
../../../../../../p4600/lib/no-rtmon.rel
/opt/rtems/mips64orion-rtems/lib/libc.a(dtoa.o): In function `_dtoa_r':
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
collect2: ld returned 1 exit status
# mips64orion-rtems-gcc -v
Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.1/specs
gcc version 2.95.1 19990816 (release)
# mips64orion-rtems-ld -v
GNU ld version 2.9.5 (with BFD 2.9.5)
The old system would panic when the loopback interface was included as
part of the network initialation structures. With the printf you get an
message, but the interface is still properly initialized.
from Eric Norum <eric@cls.usask.ca>. This patch was rtems-19990820-0-diff
from Ralf.
FYI: In parallel to the transition to automake, RTEMS is on a transition
from make-time configuration to per-bsp and per-bsp configuration at
configuration-time. Due to this several changes to configuration files
have been added and might have broken something that has been working
previously. Most noticeable behavioral change is that you now are required
to use @RTEMS_BSP@ instead of $(RTEMS_BSP) inside of any Makefile.ins
which are configured or build as part of the source-tree.
> It used to be that only RTEMS_MAKEFILE_PATH had to be set. Why is this
> no longer sufficient?
It should still be working, if it doesn't, it has to be considered to be
broken and should be fixed.
I am not sure, but I assume you are using Makefile.inc - In this case, you
have found a bug in Makefile.inc.in which should be worked-around by the
patch below. If my assumption is wrong, I would need more details ...
c/src/lib/librtems++ and c/src/lib/include/rtems++ to
their own package librtems++ at the top of the tree.
To apply:
mkdir c/src/librtems++
cp c/src/lib/librtems++/README c/src/librtems++
mkdir c/src/librtems++/src
cp c/src/lib/librtems++/*.cc c/src/librtems++/src
cp c/src/lib/librtems++/Makefile.in c/src/librtems++/src
mkdir c/src/librtems++/include
mkdir c/src/librtems++/include/rtems++
cp c/src/lib/include/rtems++/*.h c/src/librtems++/include/rtems++
patch -p1 <rtems-rc-19990802-5.diff
rm -rf c/src/lib/librtems++
rm -rf c/src/lib/include/rtems++
./autogen
Attention:
* The procedure above copies the files first, then patches them
and finally removes the old files afterwards. This has been done
to enable you to copy the files in CVS to preserve their history.
Somehow a nasty bug has made it in sh/start.S ("|", instead of "!", to
begin an asm comment).
I have no idea how this could remain undiscovered for so long (It is in
rtems-4.0.0, too!), however upgrading to binutils from sourceware's CVS
sh-rtems-as chokes on this bug. => I guess, either binutils changed its
conventions or an obvious bug in as has been fixed.
This patch addresses a few configuration issues and removes some
duplicate configuration files.
Background:
* some files used in AC_INIT were not unique enough and can lead to
problems if a user plays with configure scripts.
* the Makefile templates are independent of the target/cpu and bsp, so
the bsp dependent versions (c/src/make/Templates) are removed.
To apply:
patch -p1 < rtems-rc-19990820-3.diff
rm -f c/src/make/Templates
./autogen
ATTENTION: This patch removes several files and one directory :)
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is at
least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from running
acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
The patch below actually consists of 3 patches:
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is
at least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from
running acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
I expect this patch not to have any influence on normal users, unless
they use --enable-maintainer-mode, thus merging it should be rather
harmless.
The patch below actually consists of 3 patches:
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is
at least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from
running acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
I expect this patch not to have any influence on normal users, unless
they use --enable-maintainer-mode, thus merging it should be rather
harmless.
