"building binutils for target" question

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Fri Mar 25 16:07:00 GMT 2011


Michael, All,

On Friday 25 March 2011 16:35:15 Michael Zintakis wrote:
> Many thanks for the prompt reply on this. I also take the opportunity to 
> thank you for the absolute fantastic tool you have created - it is just 
> brilliant and although I wouldn't say I built my toolchain without any 
> hitches, it, however, saved me a *lot* of long fruitless hours of hard 
> labour!!! Once again, a truly superb piece of work, thank you!

Cheers! :-)

> >> At the end of the process binutils for the target architecture 
> >> (build=x86_64, host=target=powerpc) were also successfully "installed", 
> >> though I cannot find any of them, apart from the shared objects which 
> >> are all in sysroot! Executables like "ar", "ld" etc which should have 
> >> been compiled and installed to run on the target system (powerpc) cannot 
> >> be found anywhere (only those for the host arch are present). Am I 
> >> missing a trick here or do I have to compile and install another set of 
> >> binutils from source for my target image?
> >>     
> >
> > The binutils for target will only build some of the binutils libraries.
> > They are needed to build stuff like oprofile, and have to match the
> > version of binutils used for in the toolchain. That's why there is the
> > option.
> >   
> In other words the "binutils for the target" are for sole use by the 
> toolchain and nothing more, right? If so, that's fair enough, I just 
> wanted to be clear on this.

They are not used in the toolchain itself. The reasoning behind this
feature is:
- one might want to run oprofile on the target,
- but oprofile requires the same libbfd (and libiberty?) as was used
  to build the binaries it is profiling.

So it seemed adequate that crostool-NG would provide those libraries
to run on the target.

OTOH, providing a complete binutils to run on the target is not the
responsibility of building the cross-toolchain. It is a completely
different stuff.

When I think about it, it is not a completely different matter. The
native toolchain on the target should also have this features:
- provide the same API:
  - same headers from same kernel
  - same headers from same libc
- provide the same ABI:
  - same headers from same kernel
  - same gcc and its config options
  - same libc and its config options
  - same binutils and its config options
and so on...

So *maybe* it makes sense to build the cros-native toolchain along with
the cross-toolchain...

> Do you envisage any problems if I try to build and install a copy of 
> binutils for the target in my image root (build=x86_64, 
> host=target=powerpc) using the cross compiler built by the toolchain? 
> Would that be a problem do you think?

Building binutils should be fairly easy. Just be sure to use the exact
same version and options and patches that were used to build 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... :-/

> > To build the complete binutils to run on the target (eg. ar, ld...)
> > means to build a cross-native toolchain, which is not currently
> > supported by crostool-NG ( although I'm working on it, but there's
> > only 24h in a day! ).
> >   
> No, no! I am happy with the "cross" build as it is. I am also happy to 
> do one additional step and build binutils for the target - I am going to 
> use the cross compiler from the toolchain to build *all* of the software 
> for the target system anyway (including the kernel, another gcc etc) so 
> one additional step won't make a huge difference.

Basically, everything should be easy, except for gcc (see above).

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.

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!).
I've never done this, so I can't really tell whether it is easy or not...

> One additional query - ct-ng starts with installing the kernel headers 
> and by what I looked at they are in sysroot.

Yes. For Linux-based systems, kernel haeders are required to build the C
library, because they export the userland API+ABI of the kernel. In the
Linux world, the kernel does change its userland API+ABI, so that it
can make use of new syscalls: AIO, splice... So the C library has to
know what the kernel provides, to be able to use it, or fake it (eg. AIO
could be faked by use of threads if the kernel does not have it)

But we do not install the kernel headers as-is. We install sanitised
headers, of which all kernel internals are ripped out, so that only the
kernel <-> userland API+ABI is exposed.

> For my target machine I also need to install the same kernel (although 
> for different architecture which is the same arch as my files in 
> toolchain's sysroot),

The kernel headers that are installed are those of the architecture of
the target, of course, so that target-specifics (eg. byteswapping and
such) does indeed work when included by cross-compiled programs.

> so do I have to explicitly execute "make  
> install_headers" for the target image sysroot or is there any trick I 
> could use to "copy" the headers already installed in the toolchain's 
> sysroot? Would that be enough?

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.

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



More information about the crossgcc mailing list