This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.


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

Re: newlib or glibc ?


Brendan wrote:

> I wish to cross compile gcc to m68k and ppc embbedded systems.  I wish
> to be able to cross compile on Linux and Win32 platforms and generate
> exactly the same output files.  ie.  I prefer to use Linux while other
> coworkers prefer to use Win95.  To use the cross-compiler I need (not
> needed but prefer to have) a standard C and C++ library.
> 
> Do newlib and glibc do the same/similar thing ?
> From my understanding they are both standard C libraries.
> If they are interchangeable then I would think that glibc would be
> better as it is used in naitive GCC ports to OSs such as Linux and
> Win95.

 Linux is the only system supported in glibc-2.0.x. Cygwin32 uses
newlib.

> This would make simulating things more consistant as the same C
> libraries would be used on the hosts and the embedded systems.

 Newlib doesn't support Linux, but has a minimal support for SVR3.2
for i386 (sysvi386). This can easily be bettered just by adding more
SVR3.2 and SVR4 syscalls.

 Linux runs SVR3.2 COFF and SVR4 ELF binaries with the ibcs2 emulation
layer. The SVR3.2 support seems quite complete, but the SVR4.2 (UnixWare)
emulation lacks some syscalls.

> Any ideas which would be the best way to go ?

 Please look at 'www.nettilinja.fi/~ankosken' for a Win32-host, i386coff-
target compiler (currently 2.7.2-970404, but will be upgraded to 2.8.x or
egcs-1.x.x when I care to integrate RTEMS libraries to it...). The C-library
is in two parts: the 'opsys'-independent routines in 'libc.a' and the low-
level I/O-routines etc. in the system-'glue' library. There are two 'glue'
libs: one for SVR3.2 read()/write()/... and second for DOS/go32 equivalents.
The third, for embedded single-chip-PC's like AMD Elan, NSC 486SLX etc. is
still empty, just waiting the RTEMS routines for low-level I/O etc.  Also,
testing the '-msoft-float' routines (fp-bit/dp-bit), coming with GCC sources
is one 'speciality' of this distribution. How to make a 'simulator' to run
DOS/go32-COFF binaries under a Win32-based GDB (they run from the Win32
command line -- so why it couldn't be possible to run them under a multi-
window-GDB-GUI?) is one possible add-on (if someone knows how to do it...)
Or, perhaps making a cygwin32-glue library for this would allow running the
binaries under the cygwin32-GDB...

 There is a SVR3.2 (SCO) target, SCO-compatible-host (e.g. Linux) gcc-2.7.2
too, with glibc-1.09 as the C-library. But there shouldn't be any troubles
with taking the newlib-1.8.0 headers & i386coff libs from the Win32-hosted
compiler and using newlib with this too. I have separate i386-coff-target
(later i386-rtems) and i386-sco3.2-target compilers under Linux, however, but
using the multilib system with separate subdirs for svr32, go32 and rtems
would allow using the same compiler for them all (with '-msvr32', '-mgo32' and
'-mrtems' machine options in the command line)...

 The aim really is to make possible to develop i386coff code for a RTEMS-
based x86-system either under Linux, SCO (OpenServer5 and UnixWare are
also free for students, home users etc.) or Win32.  Perhaps a SCO-target
compiler with a 'minimal C-library' without network & X11 libs would be
of some use too... 

> Has anyone tried both on embedded systems ?  If so what were the results
> ?  eg. performance, code size, etc.

 Not yet, but 'really soon now'... Ok, a project made 'just for a fun'
would make progress much better if there were more people in it and
somebody testing the tools sometimes...

 Regards,  Kai