Mail Archives: cygwin/2009/11/03/09:23:22
Marcel Rutten wrote:
> building the toolchain is done in 4 steps:
>
> 1 build binutils,
> 2 build gcc stage 1, a barebones gcc, for building glibc
> 3 build glibc
> 4 build gcc stage 2, with c and c++ support.
>
> Things go wrong in step 3, the linker starts complaining about
> undefined references, all referring to weak symbols( __open and a
> bunch of others ).
> Obviously, the cygwin versions of gas and ld should support weak
> symbols when compiling for arm-linux-gnueabi, before my plan of
> building this toolchain will succeed.
The versions you built in step 1, yes.
> What I don't see is why the host platform has to support weak symbols
> (in PE-dll's) before the compiler/linker for the target platform can
> use them as well.
It doesn't. The real problem is either that the tools you built in step 1
didn't get the right --target setting and ended up being native tools, or that
the glibc configure in step 3 is for some reason failing to find them and ends
up invoking the native tools.
> Else, if I install a compiled version of glibc for the target
> processor (built on another platform), then build gcc stage 2, could
> that be useful and lead to a working toolchain?
The technique of taking a copy of the real sysroot (libs and include dir)
from a live target (or a distro mirror/install cd/whatever) and building your
compiler against that, rather than bootstrapping the whole library from
scratch, has lots to recommend it, and should be somewhat simpler. It'll
still need to be able to find the correct target binutils, though, no matter
what; you need to solve that problem first I think.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -