Re: "building binutils for target" question

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Michael, All,

On Friday 25 March 2011 17:31:13 Michael Zintakis wrote:
> > So *maybe* it makes sense to build the cros-native toolchain along with
> > the cross-toolchain...
> >   
> It does as I cannot see too many scenarios where someone would want to 
> build a "cross" chain and leave it there.

Generally, a native toolchain is not required on the target. All programs
are cross-compiled to run on the target.

For example, on small routers, there is no room to store a complete
toolchain, and they are not powerfull-enough to even run a toolchain.

So basically, cross-compiling a native toolchain that does run on the
target is not usually needed.

> It has to be used for some purpose - i.e. building other programs for 
> the target arch - but more often than not these programs are dependent 
> on the basic target libraries like glibc, binutils etc so it makes 
> perfect sense to build and include these as well as part of the whole 
> process.

Yes, that's what the cros-toolchain is meant for: cross-compiling
programs that run on the target.

But if you also want to have a native toolchain on the target is a
completely different matter to having a cros-toolchain.

So the question is: do you need to run a compiler on your target?
If the answer is 'no', then all you need is the cross-toolchain.

> > Building gcc might be a bit more delicate... gcc is really not playing
> > nice when it is cross-compiled. Hence the time it takes to properly
> > finish the canadian-cross patch series I'm working on... :-/
> >   
> Bugger, so --build=x86_64 --host=powerpc --target=powerpc won't be as 
> easy you reckon?

No, I'm afraid that's not that simple... :-(
It should be, but it is not...

> I intend to adopt similar steps as when the toolchain  
> was build - static gmp, mpfr, then ppl, cloog,  and binutils, after that 
> use the already built glibc and try to build "cross-native" gcc (see my 
> question on that in the next paragraph).


> > Remember that you already have a C library on the target, so you will not
> > need to build it again. You will have to tell gcc where to find it.
> >   
> OK, but, presumably, when I construct that final image glibc should also 
> be there (in the final image), right? how do I "move it across"? Where 
> is it located (for the target arch)?

Basically, you would follow these steps:
- build the cross-toolchain ( with crostool-NG, of course! ;-) )

- build every packages, and install them in what we call a 'staging area':
  ./configure --build=x86_64-blabla --host=powerpc-blabla --prefix=/ --options
  make
  make DESTDIR=/some/place/staging
  (note: you may need to pass additional CFLAGS and LDFLAGS, such as:
    CFLAGS="-I/some/place/staging/usr/include -I/some/place/staging/include"
    LDFLAGS="-L/some/place/staging/lib -L/some/place/staging/usr/lib"
  )
  Note: do NOT install in the sysroot! If you do so, then you won't be
  able to reuse the toolchain, as it would be poluted with headers and
  libraries from your programs. You really want to install in a staging
  area!

- the staging area will contain all that your packages have installed, but
  is missing the 'system' libraries from the toolchain. So crosstool-NG
  does provide a tool that can complete the staging for you. That tool is
  called populate:
    powerpc-blabla-populate -s /some/place/staging -d /some/place/rootfs
  populate will scan all binaires (executable and shared libs) in staging,
  find missing NEEDED libs and get them from the sysroot, and create a copy
  of staging in rootfs, which will contain all libs required to run.
  Note: if you are using glibc, be sure to add (some or all of )the NSS
  libraries. You can do it with the '-l' options of populate. See:
    docs/5 - Using the toolchain.txt
    populate --help

- you then create an 'image' of rootfs that you transfer to the target
  and boot on that. It all depends on your target what this image will be:
  - file system image to burn on flash
  - tarball to extract on SD or HDD, or to NFS mount
  - kernel+initrd to boot from the network
  - and so on...

> > Also, you will want to build gcc without sysroot support, and tell it that
> > headers and libs are in /lib. /usr/lib and /usr/include (respectively!).
> >   
> Presumably these libraries and headers should already be present in 
> those directories, right? If so, then I would definitely need to run 
> (and install!) gmp, mpfr etc together with binutils and either 
> "move/copy" the glibc files from my cross toolchain or build another 
> glibc from scratch using the cross gcc built by the toolchain. Does that 
> seem plausible to you Yann?

If you need a native toolchain on the target, probably, yes.
But then, you would not install it in the sysroot, but in a staging area,
as explained above.

> > I've never done this, so I can't really tell whether it is easy or not...
> >   
> I'll give it a go as it is my first time for me as well ;-)

First times are often a bit  painful... :-]

> > You do not need to copy or install them again. The cross-gcc and cross-ld
> > will be able to find them (and the libs) automatically. This is the purpose
> > of the sysroot.
> >   
> What about my "cross-native" gcc and the binutils I am going to build? 
> Would they be able to find them (or should I use the --with-headers 
> option when running configure, would that be enough do you think)?

You would need to build the native gcc using the already built sysroot. Just
copy the sysroot of the cross-toolchain, and use that copy to configure gcc.
You could start by creating your staging by entirely copying the sysroot
as-is, and then configure gcc with --disable-sysroot and --with-build-sysroot
that points to the staging.

Of course, in this case, you would not need to run populate, as your staging
will already have everything...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq