This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: powerpc-eabism, strategy for finding crt0.o
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: powerpc-eabism, strategy for finding crt0.o
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: 12 Apr 2001 00:30:20 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <200104111841.f3BIfiI16248@fillmore.constant.com>
Benjamin Kosnik <bkoz@redhat.com> writes:
> Geoff, powerpc-eabism targets use libgloss to deal with crt0.o. If I'm
> going to get libstdc++-v3's testsuite working correctly with the
> target, I'm going to have to find crt0.o so that it can be linked in
> to resolve things like _start, and __eabi. I don't see an existent way
> to do this, please correct me if I'm wrong.
>
> One option is linking
> (builddir)/powerpc-eabism/libgloss/rs6000/crt0.o
> to
> (builddir)/powerpc-eabism/newlib/crt0.o
>
> Another option is to pass down NEWLIB_SUPPORT_DIRS from the toplevel
> makefile, thus allowing target libs to know that libgloss is in
> play. Then the trick is finding crt0.o: for a --target=powerpc-eabism,
> the holding directory is 'rs6000'.
>
> it would be nice to just be able to do
>
> (builddir)/powerpc-eabism/NEWLIB_SUPPORT_DIRS/$(target_cpu)/crt0.o
>
> can't do that now though, but I suppose a sym-link could be made at
> build time that allowed this.
>
>
> What seems like the best approach?
How about doing it the way the g++ testsuite does it (whatever that
is)? I think that dejagnu knows about libgloss in various special
ways, see for instance this code:
set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]"
set_board_info ldflags "-msim [libgloss_link_flags] [newlib_link_flags]"
in powerpc-sim.exp. So in theory if you just build and link
"properly" (using cflags and ldflags), everything should work. Note
that -msim is required, and for other boards other flags will be
needed (it's very common to require some linker script option, for
instance "-Tidt.ld" on mips for IDT boards.)
(I was going to ask 'what's wrong with doing it...', but I immediately
thought of dozens of ways the current way is wrong.)
Yes, I agree that the _best_ way to do it would be to simply do
g++ -B $builddir/ -L $builddir/lib -L $builddir/$target/lib foo.cc -o foo
./foo
and arrange things so that $builddir/lib and $builddir/$target contain
the right things: crt*, linker scripts, libc.a, libstdc++.a, header
files, and whatever else is needed to compile and link a program.
That way, lots and lots of crud could be removed from dejagnu and
makefiles.
--
- Geoffrey Keating <geoffk@geoffk.org>