Jordan,
I can take a look (when I get some time) at how to have buildroot do the LAB payload. Either this or use the crosstools scripts to do it. Both will create a cross-compiler and build environment.
I will prob not be able to get to this for a few weeks, I will be on vacation next week and have some other tasks I need to get done.
Marc
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Jordan Crouse wrote:
On 16/05/08 08:51 -0400, Marc Karasek wrote:
Jordan, et all,
There is one caveat to my previous email.
Currently for LAB busybox is compiled with uClibc using the -nostdlib option. According to the uClibc FAQ is no longer supported (since 0.22). It was handled through a toolchain wrapper and the uClibc guys decided that it was too much of a problem in maintaining it and pulled the support. They now recommend building a toolchain with buildroot and using this to compile your application/program.
This is indeed a problem, and even more makes me think that we're going to need to turn to an outside build engine (such as buildroot) to build our LAB images.
Jordan
Marc Karasek wrote:
Jordan,
I agree with you about it being more of a coreboot problem than a toolchain problem. (Although, building a cross-compiler is really quite simple, if you use the crosstools scripts. It is just a matter of running a script.) I will put together all of my information on what is broken and what errors I am seeing as soon as I can.
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking. This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
I like the idea of being able to "specify" a local toolchain. This would give someone the option to compile and build with a "known" good toolchain. I feel this is useful in that toolchain problems can be very difficult to track down. They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling. This would provide a path for someone to continue on with their development/testing while (potentialy) someone else looks at the build problem.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Marc
Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415
Jordan Crouse wrote:
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues
we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan