This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: How was newlib supposed to have been used?

On 18 January 2008 12:23, Ralf Corsepius wrote:

> On Fri, 2008-01-18 at 12:09 +0000, Dave Korn wrote:
>> On 18 January 2008 06:45, Ralf Corsepius wrote:
>>> On Thu, 2008-01-17 at 23:57 +0000, Luke A. Guest wrote:
>>>> On Thu, 2008-01-17 at 13:43 +0100, Ralf Corsepius wrote:
>>>>> Neither, nor and all of it.
>>>>> newlib is a libc implementation.
>>>> Yeah, I'm aware of this :/
>>>>> I.e. it is a library providing a standardized API to resources
>>>>> underneath, which applications might want to use at run-time, and which
>>>>> toolchains (compiler/linker etc.) will want to know about.
>>>> And this too.
>>>>> What these resources actually are is secondary. They can be
>>>>> "bare-metal", a full fledged kernel or other libraries.
>>>>> Newlib can be and is being used in all of these situations.
>>>> Right, so as I'm aiming for bare hw, am I going in the right direction
>>>> to get *a minimal GNAT runtime* working for i386-elf (and mips[el]-elf)?
>>> I don't know how to answer this.
>>> GNAT, normally is a toolset implementing a programming language (Ada)
>>> built around/ontop of a libc. 
>>> Leaving aside all other ugliness of GNAT, I am not sufficiently familiar
>>> with Ada to be able to judge how far you can get without at least having
>>> some OS-elements (processes, memory-management, io, etc.) available.
>>   I have no personal experience with GNAT[*], but a google "gnat newlib"
>> suggests that RTEMS, at least, does use or has used newlib to support GNAT
>> on target i386-rtemscoff-gnat-newlib among others.
> Please note my email address :-)

  Well, /you/ didn't mention it, so someone had to!

> RTEMS uses newlib as it's libc. For some (few) targets, some people
> reported to have been able to build a GNATS enabled GCC ontop of it.
> GNATS/RTEMS run-time support is spread into GCC and RTEMS own run-time
> libs.

  Don't suppose there's any documentation about the division of
responsibilities is there?

>>   You might be able to get
>> somewhere by adapting the instructions at
> Well, yes, ... you might ask yourself why this page exist, and why GNAT
> is not part of the official RTEMS toolchains ;)

  Well, actually I was going to leave Luke to work on that!  Maybe porting
RTEMS to his board might be the easiest way to get Ada running; option 2 would
be to just try and hack/stub out the bits of runtime that aren't supported;
option 3 would be to try and build gnat/newlib and just add the missing
support.  It's not easy to say from this end which is likely to be the
quickest solution for Luke's situation - but it's probably possible to say
that porting glibc would be the slowest!

Can't think of a witty .sigline today....

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]