Re: ARM build fails in libgloss: no redboot.ld

[Jeff Johnston <jjohnstn at redhat dot com>]

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