[coreboot] Now Proposal for cross-compiler Re: Simnow & payloads (Was: something else)

Marc Karasek Marc.Karasek at Sun.COM
Tue May 20 14:15:02 CEST 2008


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




More information about the coreboot mailing list