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