This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tutorial


Trevor, All,

On Thursday 24 February 2011 21:28:00 Trevor Woerner wrote:
> I was wondering if any progress has been made on this project? A quick
> scan of the ct-ng website doesn't appear to contain any such tutorial

Not yet, indeed. I have been working on this. I have something in a local
tree, but it is not yet ready.

I'm not doing a tutorial, but an explanation of the overall process, and how
every bit fit together. That document ought to be as complete as possible,
yet easy to read; this is a tedious work, but I've made some progress...

> I was hoping to see more explanations of:
> 1) sysroot (what is it, what is it used for, how is it specified)
> 2) how one goes about building the various phases of compilers/C-libraries
> 3) and hopefully more on the subject of what happens after the tool is
>    complete

All planned to be included in the doc.

> For example:
> 
> 1) I know that back when I was building my own cross compilers I would
> sometimes end up in the situation where the final compiler and C
> library were installed in, say, my $HOME directory. When I would build
> and install a cross application on the target it would fail to run
> because it was looking for the libraries in my $HOME directory (which
> didn't exist on the target). I know that at the time I was eventually
> able to figure out what was wrong and fix the problem, but I can't
> even begin to remember what the problem was and how I fixed it.

C library runtime prefix mishap, probably...

This is documented in the glibc installation notes at:
  http://www.gnu.org/software/libc/manual/html_mono/libc.html#Linux

<quote label="Black Magic & Voodoo at work here">
  GNU/Linux expects some components of the libc installation to be in /lib
  and some in /usr/lib. This is handled automatically if you configure glibc
  with â--prefix=/usrâ. If you set some other prefix or allow it to default
  to /usr/local, then all the components are installed there.
</quote>

Basically, this means that if you configure glibc with anything else than
--prefix=/usr then you are shooting yourself in the foot. :-]

> 2) I also know that there were times when I was cross compiling
> applications for the target on my build machine that header files from
> the build machine would interfere with my compile. So my compile would
> end up erroneously using files from, say, my host's /usr/include
> instead of the corresponding files from where my cross tools had been
> installed. I don't think I ever got that one solved with 100%
> confidence.

Yes, I understand. Basically, the sysroot mechanism is there to solve this
issue (as well as others, such as finding the libs).

But this only means where _gcc_ and _ld_ (and other tools in the toolchain
itself) will look for to find the required files.

If your package's configure and/or Makefile have hard-wired path such as
/usr/include and/or /usr/lib to find headers/libs, then there is nothing
that can be done from the toolchain's point of view.

> I realize ct-ng is only about the tool and not about building root
> filesystems, but I was hoping these topics would be considered
> relevant enough to be included on any such tutorial.

This problem is tangential to the one crosstool-NG strive to solve. I agree
that the two are related, and crosstool-NG *could* include some *hints* at
how to use the toolchain. In fact, there is already such a suggestion
presented in:
  docs/5 - Using the toolchain.txt

Agreed, it *could* be expanded. But what would go in? How you use the
toolchain is really up to you, and really depends on your environment.
Every build systems are different from each others, and it's difficult
to extract a generic rule-of-thumb...

I'll push the updated doc later tonight, so interested parties can comment
and provide enhancements and/or fixes.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]