[ECOS] Using a different Standard C library.

[ECOS] Using a different Standard C library.

[tmm]

Some of the eCos packages that I'm using require the Standard C library 
so I've included the CYGPKG_ISOINFRA (ISO C & POSIX Infrastructure) 
package and several of the CPYPKG_LIBC_* packages.

But, I would rather use a different C library: the one that comes with 
my Code Sorcery ARM compiler.  Though this is not the normal eCos way, I 
assume that it is not too unusual.  But how is this typically done?

I will probably continue to make my eCos library using the eCos C 
library headers.  But I would hack the makefiles so that the source code 
for the C library packages doesn't get included in the my projects' 
library.  In place of the eCos C library code I would link in my own C 
library when I link my applications.  (When I write 'my own' C library I 
mean the compiler's.)

The tricky part of this is the 'ISO C & POSIX Infrastructure' package.  
This contains a mix of code that I do need (the POSIX stuff) and code 
that will be provided by my C library.

Perhaps instead I should take the code of my C library and replace the 
eCos C library code with it (and make corresponding changes to the 
package definitions)?

Thanks for any suggestions,
Tom.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Using a different Standard C library.

[Andrew Lunn]

On Wed, Dec 19, 2007 at 06:51:49PM -0500, tmm wrote:
> Some of the eCos packages that I'm using require the Standard C library so 
> I've included the CYGPKG_ISOINFRA (ISO C & POSIX Infrastructure) package 
> and several of the CPYPKG_LIBC_* packages.
>
> But, I would rather use a different C library: the one that comes with my 
> Code Sorcery ARM compiler.  Though this is not the normal eCos way, I 
> assume that it is not too unusual.  But how is this typically done?

Actually, i've never heard anybody wanting to do this. Taking a step
backwards, before getting into the messy details, why do you want to
do this? What is wrong with the eCos libc?

> I will probably continue to make my eCos library using the eCos C library 
> headers.  But I would hack the makefiles so that the source code for the C 
> library packages doesn't get included in the my projects' library.  In 
> place of the eCos C library code I would link in my own C library when I 
> link my applications.  (When I write 'my own' C library I mean the 
> compiler's.)
>
> The tricky part of this is the 'ISO C & POSIX Infrastructure' package.  
> This contains a mix of code that I do need (the POSIX stuff) and code that 
> will be provided by my C library.
>
> Perhaps instead I should take the code of my C library and replace the eCos 
> C library code with it (and make corresponding changes to the package 
> definitions)?

Do you have the sources to the c library you want to use? Is it nicely
separated out into stdio, string, time, etc. Are the bottom interfaces
well defined and documented. eg is it clear how you are supposed to
interface it to the serial ports, mutex's etc, interrupt handling
etc. The eCos libc is not well documented, so i don't actually know
what it needs.

You say you want POSIX. Does that include signals? Does your libc
support signals, ie "system calls" being interrupted and should return
EINTR?

I think you have a lot of hard work in front of you. The question is,
is it worth it?

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss