ARM build fails in libgloss: no redboot.ld

[Jeff Johnston]

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 configure.in
> 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 configure.in.

>   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:

CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM or
CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM

-- 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 Makefile.in 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.
>>
>>shap
> 
>