How to build librtemscpu.a and librtemsbsp.a in the future?

Chris Johns chrisj at
Sun Mar 25 03:20:41 UTC 2018

On 24/3/18 1:27 am, Sebastian Huber wrote:
> Hello,
> I tried to consolidate the cpukit This ended up in the following
> problem. The content of librtemscpu.a depends on the CPU port. This is currently
> done via a non-standard
> construct.

Where is this? I cannot find it.

> The wrapup/ combines several static libraries into one
> librtemscpu.a. With we have a similar problem. This archive
> unpack and re-create step seems to be a bit expensive.

Yes this is an awkward work around. I seem to remember this is borrowed from
automake and adapted for us. No matter where is comes from it is a hack and a
pain to maintain. With nested makes we do not have access to the list of objects
so we need to extract, capture and create to merge.

> Why can't we use an MRI script, e.g.
> create ./sparc-rtems5/erc32/lib/librtemscpu.a
> addlib ./sparc-rtems5/c/erc32/cpukit/librtemscpu.a
> addlib ./sparc-rtems5/c/erc32/cpukit/score/cpu/sparc/libscorecpu.a
> save
> end
> ?

If this was supported by the standard GNU script I would be more receptive but
even then I feel it is papering over build system weaknesses. Is the MRI format
still alive in any MRI or Mentor products?

> Would conditional parts be more efficient, e.g. in cpukit/
> if CPU_ARM
> include score/cpu/arm/
> endif
> if CPU_XXX
> ...

I think this would be a major piece of work. You would need to make sure any
globals at the make level do not step on each other.

> How would waf deal with this problem?

Efficiently. See:


More information about the devel mailing list