[coreboot] Now Proposal for cross-compiler Re: Simnow & payloads (Was: something else)
Jordan Crouse
jordan.crouse at amd.com
Mon May 19 19:23:35 CEST 2008
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 at 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
>>>
>>>
>>
>>
>
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot
mailing list