ARM build fails in libgloss: no redboot.ld
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 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
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.
> 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.
More information about the Newlib