ARM build fails in libgloss: no redboot.ld

[Jonathan S. Shapiro]

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?
  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.

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?

Thanks

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