crt0 not built for m68k target?
Thu Oct 6 15:50:00 GMT 2005
If you look at configure.host you will notice a variable: have_crt0.
This variable is set by default to yes if 1. you have a sys_dir and 2.
you don't specify: have_crt0=no When this variable is set to yes, the
libc/sys expects to copy crt0.o up the tree.
If your sys directory builds crt0.o conditionally, then you will have to
modify your configure.host to conditionally set this variable to no.
-- Jeff J.
Jonathan S. Shapiro wrote:
> I'm sure this will turn out to be a perfectly obvious configuration
> error, but...
> As you all know, I've been porting newlib for use in Coyotos. I now have
> a working tool chain for i386. The substantive patches amounted to:
> 1. Add coyotos in src/config.sub
> 2. Add coyotos target in src/newlib/configure.host:
> Note that nothing in this config is target architecture dependent.
> I hacked a sys/coyotos/ tree based on rtems, which provides its own
> crt0.c, but assumes that crt0.c will be build from a board support
> package. Coyotos doesn't have any board support packages (yet).
> The attempt to build m68k-unknown-coyotos target fails with:
> make: Entering directory
> rm -f lib.a
> ln coyotos/lib.a lib.a >/dev/null 2>/dev/null \
> || cp coyotos/lib.a lib.a
> rm -f crt0.o
> ln coyotos/crt0.o crt0.o >/dev/null 2>/dev/null \
> || cp coyotos/crt0.o crt0.o
> cp: cannot stat `coyotos/crt0.o': No such file or directory
> This failure is more or less expected, since in the m68k build the
> crt0.o file isn't getting built.
> The right answer will probably turn out to be disabling crt0 altogether,
> but before I do that I would like to understand why crt0.o is built as
> expected in the i386-unknown-coyotos target, and is *not* being built
> (same sys/ directory, same makefile, same source files) for the
> m68k-unknown-coyotos target. It's not that the attempt to build crt0.c
> for m68k target is failing. What confuses me is that no attempt is made
> at all, and I'm not seeing anyplace in the makefiles that would account
> for this target-specific difference in behavior.
> I have a sinking suspicion that this is a multilib issue, and I'ld like
> to understand what is going on a little better before I mess with it.
> Can anybody provide a hint?
More information about the Newlib