ARM build fails in libgloss: no redboot.ld

Jeff Johnston
Mon Nov 28 21:44:00 GMT 2005

Jonathan S. Shapiro wrote:
> Okay. I see it -- libgloss couldn't figure out that this was an elf
> target. I updated the appropriate part of the libgloss/arm
> and things are now building.
> I remain a bit confused about the theory of operation for libgloss. It
> appears to me that libgloss is intended to provide "bare" board support.
> This raises two (naive, apologies) questions:
>   1. When an OS is present, should libgloss be disabled? How?

Usually, when dealing with an OS, libgloss is not required as the 
libc/sys directory or an external library provides the syscalls.  This 
is mostly due to the fact that an OS has a much more robust set of 
syscalls than vanilla newlib requires and libgloss generally supplies.

To disable libgloss, add target-libgloss to noconfigdirs for your target 
in the top-level

>   2. Given that an OS is not present, I would still expect libgloss
>      to be board specific, but it does not appear to have a BSP
>      hierarchy.

Not sure what you mean here by hierarchy.  If there are multiple bsps to 
choose from, then either the user must make the choice at compile/link 
time via either a spec file or ld script or the platform sets up a 
special target compile option and multilibs the libgloss library.

> While I'm thinking about it, how should own specify a configure "triple"
> when one intends to specify a specific target BSP to be built? For
> example, assuming I have made the appropriate configure file changes, if
> what I want is
> 	OS = coyotos
> 	ARCH = arm
> 	VENDOR = erosgroup
> 	BSP = coolboard
> how should this be expressed in the --target argument to configure?

BSPs are not part of the target specification.  Either:


-- Jeff J.

> shap
> On Sat, 2005-11-19 at 19:05 -0500, Jonathan S. Shapiro wrote:
>>This is probably for Jeff (?)
>>I'm cross-building newlib for an ARM target, and the build in libgloss
>>is failing. The problem seems to be that the makefile references
>>redboot.ld and redboot.spec, but those files have now been specialized
>>according to whether the target binary format is elf, coff, or a.out.
>>Is it possible that when the files were specialized the did
>>not get updated properly?
>>Actually, I'm very surprises to see the redboot stuff being built. I
>>would have thought that this would be a board-specific decision.
>>Before I go whacking the makefile, recommendations? At the moment, I
>>just want to get a valid build to happen.

More information about the Newlib mailing list