Build a toolchain for ARM with cygwin 1.5.25-15 ?

[Marcel Rutten]

Dear all,

I  am trying to set up a toolchain for an ARM platform
(arm-linux-gnueabi, my TV) using cygwin, without much success so far.
The tools I'm using are:

binutils             20080624-2
gcc4                 4.3.2-2

The toolchain code consists of:

gcc 4.2.0, glibc 2.5.90, binutils 2.17.50, linux kernel 2.6.18, rather
heavily patched for the target processor.

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 ).
After some digging I found some mention about cygwin not supporting
weak symbols in its executable format.
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.
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.
So I started searching the web again for this and ended up in this
mailing list, where recently there was some mention of weak symbols
not being fully supported by cygwin, but work on it is ongoing.

This leads me to the following questions:

If I upgrade cygwin to a newer (beta) version (1.7.x), is weak symbol
support by the binutils of that version better/good enough?
If not, is there some activity on the solution of this issue?
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?
After all, I don't care having a statically compiled toolchain, as
long as it is capable of building shared (ELF) libraries etc. for
another platform.
or should I abandon my plan altogether, maybe because weak symbol
support is not considered to be present in the foreseeable future?

Thanks in advance,


marcel

--
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

[Dave Korn-6]

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