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

[Marc Karasek]

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.

Marc

*********************
Marc Karasek
MTS
Sun Microsystems
mailto:marc.karasek at sun.com
ph:770.360.6415
*********************



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