[coreboot] Any plans to fix payload builds on 64-bit machines?

Sean McNeil seanmcneil3 at gmail.com
Thu May 22 05:36:06 CEST 2014


The below problem is known and fixed in the newer binutils. I changed 
buildgcc to:

-BINUTILS_VERSION=2.23.2
+BINUTILS_VERSION=2.24

and everything builds fine. So please confirm that CONFIG_ANY_TOOLCHAIN 
is deprecated and to be removed. If there are no plans to support it, in 
my opinion it should not be provided as a choice.

Cheers,
Sean

On 05/22/2014 09:59 AM, Sean McNeil wrote:
> I've tried your suggestion. Building binutils on my 64-bit Fedora 20 
> system:
>
> ../../../binutils-2.23.2/bfd/doc/bfd.texinfo:325: unknown command 
> `colophon'
> ../../../binutils-2.23.2/bfd/doc/bfd.texinfo:336: unknown command `cygnus'
> make[3]: *** [bfd.info] Error 1
>
> I have texinfo-5.1-4.fc20.x86_64 installed.
>
> On 05/22/2014 02:42 AM, David Hendricks wrote:
>> On Tue, May 20, 2014 at 8:51 PM, Sean McNeil <seanmcneil3 at gmail.com 
>> <mailto:seanmcneil3 at gmail.com>> wrote:
>>
>>     Are you bullding on 64-bit machine and have:
>>
>>
>>     CONFIG_COMPILER_GCC=y
>>     CONFIG_ANY_TOOLCHAIN=y
>>
>>     ?
>>
>>
>> CONFIG_ANY_TOOLCHAIN should not be used in most cases. What does your 
>> .xcompile file look like?
>>
>> I'm building on a 64-bit host using the crossgcc toolchain. Try 
>> running the buildgcc script in util/crossgcc, then rm -f .xcompile 
>> and run make and see if that helps.
>>
>> For reference, here are my .xcompile and .config files as well as the 
>> output from make.
>>>> xcompile.txt 
>> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNLVhwSHh4V0VWY28/edit?usp=drive_web>
>> ​​
>> config.txt 
>> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNZ2hEcENPQ2kwSHM/edit?usp=drive_web>
>> ​​
>> make.txt 
>> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNY1phV0c4c0MtM0U/edit?usp=drive_web>
>>>>
>>
>>     arch/x86/exec.S:1:0: note: this is the location of the previous
>>     definition
>>      /*
>>      ^
>>     arch/x86/exec.S: Assembler messages:
>>     arch/x86/exec.S:43: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:45: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:52: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:53: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:54: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:61: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:62: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:70: Error: invalid instruction suffix for `push'
>>     arch/x86/exec.S:73: Error: operand type mismatch for `call'
>>     arch/x86/exec.S:81: Error: invalid instruction suffix for `pop'
>>     arch/x86/exec.S:91: Error: invalid instruction suffix for `pop'
>>     arch/x86/exec.S:92: Error: invalid instruction suffix for `pop'
>>     arch/x86/exec.S:93: Error: invalid instruction suffix for `pop'
>>     arch/x86/exec.S:97: Error: invalid instruction suffix for `pop'
>>     make[2]: *** [build/arch/x86/exec.libc.o] Error 1
>>     make[1]: *** [libpayload] Error 2
>>     make: *** [filo] Error 2
>>
>>
>>
>>     On 05/21/2014 10:36 AM, David Hendricks wrote:
>>>     On Tue, May 20, 2014 at 6:31 PM, Sean McNeil
>>>     <seanmcneil3 at gmail.com <mailto:seanmcneil3 at gmail.com>> wrote:
>>>
>>>         All the recent changes to how the compiler is defined have
>>>         now caused payloads like FILO and SeaBIOS to not build on
>>>         X86_64 machines. Is anyone working to fix this?
>>>
>>>
>>>     I just tried building images with each of those as payloads and
>>>     they seemed to compile fine for me. Try "rm -f .xcompile" before
>>>     compiling and see if that helps.
>>>
>>>     If that doesn't work, can you post more details such as the git
>>>     version you're on and output of "make" ?
>>>
>>>     -- 
>>>     David Hendricks (dhendrix)
>>>     Systems Software Engineer, Google Inc.
>>
>>
>>
>>
>> -- 
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140522/4dd54413/attachment-0001.html>


More information about the coreboot mailing list