[coreboot] Now Proposal for cross-compiler Re: Simnow & payloads (Was: something else)
Marc.Karasek at Sun.COM
Wed May 14 23:31:49 CEST 2008
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.
mailto:marc.karasek at sun.com
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.
More information about the coreboot