Re: variation in the platform configuration for 'newlib'

[Doug Evans <dje@cygnus.com>]

   Date: Thu, 13 Mar 97 09:49:24 PST
   From: drgeorge@ilt.com (Dr_George_D_Detlefsen)

   I want to port 'newlib' to a new variiation of a basic already supported
   machine.

   I am working with the 'StrongARM' in a bare board environment without any
   debug monitor. The 'crt0.S' and 'syscalls.c' code assumes the presence
   of the 'DEMON' debug monitor which is also used in the ARM simulator.
   This code will not work on a bare board or on one using the newer
   'ANGEL' debug monitor.

   How can I make configurations for:

	   arm-semi-aout		DEMON		(existing situation)
	   arm-bare-aout		---		(bare board)
	   arm-angel-aout		ANGEL		(new ANGEL debug monitor)

   where the 'libc.a' and 'libm.a' are exactly the same but
   the lowest level code 'crt0.S' and 'syscalls.c' are different ???

We are trying to move newlib to a state where it knows nothing
about system calls [other than their names].
i.e. no system call code should live in the newlib source tree,
at least not as it stands today.

Part of the reason for this is exactly because of situations
like yours.  There are untold numbers of boards out there,
each with their own crt0 and syscall requirements.
Libgloss is where we are moving such code to, but it
will take some reorg and some time.  Plus we need to allow
developers to easily add their own without having to do
anything with newlib/libgloss source tree.

   I would like to have all three available and selectively link
   which environment is being targeted.

This is accomplishable with separate linker scripts,
and by invoking gcc -T<scriptname> ...

Take a look in the ldscripts directory of the installed tree for foo.x.
Then add lines like

INPUT(crt0.o)
INPUT(syscall.o)

to it.

This assumes that GCC won't be trying to supply crt0.o to the
linker script.  Try gcc -nostartfiles if that happens.
[Ideally, GCC wouldn't be trying to provide crt0.o so you wouldn't
have to supply -nostartfiles.]