Which automake version to use with RTEMS?

Jiri Gaisler jiri at gaisler.se
Tue Dec 5 20:34:33 UTC 2017


On 12/05/2017 09:01 PM, Joel Sherrill wrote:
>
>
> On Tue, Dec 5, 2017 at 1:55 PM, Jiri Gaisler <jiri at gaisler.se
> <mailto:jiri at gaisler.se>> wrote:
>
>     Building RSB installs automake-1.12.6, but RTEMS Makefile.am files
>     seem
>     to need (exactly) automake-1.13. On top of that, many linux
>     systems have
>     1.15 installed by default. Is there a reason why RSB installs
>     1.12.6 and
>     not 1.13? And why can't we use 1.15?
>
>
> My recollection is that our automake version has some patches but the
> bigger problem is that automake dropped support for some of the old
> Cygnus early features. Those were in use and we would rather move
> to waf then invest effort in doing major work on the autotools version.
>
> Which files  claim to need 1.13?

This is what I get with 1.12 :

jiri at carbon:~/ibm/src/rtems/rtems.git/c/src/lib/libbsp/riscv/riscv_grlib$
/opt/rtems/5/bin/automake
configure.ac:14: error: version mismatch.  This is Automake 1.12.6,
configure.ac:14: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:14: comes from Automake 1.13.  You should recreate
configure.ac:14: aclocal.m4 with aclocal and run automake again.


This is what I get with 1.15 :

jiri at carbon:~/ibm/src/rtems/rtems.git/c/src/lib/libbsp/riscv/riscv_grlib$
/usr/bin/automake
configure.ac:14: error: version mismatch.  This is Automake 1.15,
configure.ac:14: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:14: comes from Automake 1.13.  You should recreate
configure.ac:14: aclocal.m4 with aclocal and run automake again.
Makefile.am:54: warning: source file '../../shared/bspreset.c' is in a
subdirectory,
Makefile.am:54: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled.  For now, the
corresponding output
automake: object file(s) will be placed in the top-level directory. 
However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option
throughout your
automake: project, to avoid future incompatibilities.
Makefile.am:54: warning: source file '../../shared/bspstart.c' is in a
subdirectory,


With 1.13 it works, but I still get some weird warnings:

jiri at carbon:~/ibm/src/rtems/rtems.git/c/src/lib/libbsp/riscv/riscv_grlib$
automake
Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at
/usr/local/automake-1.13/bin/automake line 3922.


My bsp is based on the sparc/leon3, and I have reused all Makefile.am
from there ....
>
> and be sure that RTEMS tools are at the front of your path. But you
> know that. 
>
>
>     Sorry if this is a dumb question, but I am trying to bring up a
>     new bsp
>     and have problems with generating the proper Makefiles ...
>
>
> New BSP... :)

Well, I have designed a simple RISCV processor and slotted it in the
GRLIB SOC system (replacing LEON3). I also have a sis simulator running
RISCV and simulating the whole thing. What I am trying to do is to make
a bsp (riscv_grlib) under libbsp/riscv that reuses all of the
sparc/grlib/amba drivers (without duplicating them). This needs some
trickery in the Makefiles since I try to use files from a different cpu
port...  Ideally, all grlib/amba drivers should be in libchip or
libbsp/shared rather then in the sparc port, but I don't want to
change/break anything outside the riscv port.

Anyhow, I can run hello.exe at the moment but I have some problems with
initializing interrupts. (and generating Makefiles) ...

Jiri.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20171205/4a3caabd/attachment-0002.html>


More information about the devel mailing list