Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Fischer <rep.dot.nop@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] problems building x86_64 target
Date: Wed, 6 Jun 2007 19:38:26 +0200	[thread overview]
Message-ID: <20070606173826.GA4543@aon.at> (raw)
In-Reply-To: <3AF470EE-B97B-40FC-B806-12627EC946D0@lanl.gov>

On Tue, Jun 05, 2007 at 10:16:26AM -0700, kevint wrote:
>Hello,
>
>This is my first post to this mailing list, so please excuse (and  
>point out) anything that doesn't follow the list's protocol.
>
>I have been trying to build an x86_64 toolchain using different  
>buildroot snapshots, uClibc versions, gcc versions.  I have  
>successfully built i386 images with several configuration  
>combinations, but no configuration combinations are providing a  
>successful build for x86_64.
>
>The two most common errors I come across are the following (using  
>buildroot-20070605.tar.bz2):
>
>(1)
>Target Architecture: x86_64
>Target Architecture Variant: opteron
>uClibc C library version (uClibc 0.9.29)
>(toolchain/uClibc/uClibc-0.9.29.config) uClibc configuration file to  
>use?
>GCC Compiler version (gcc 3.4.6)
>
>All other options are default.  This is my desired configuration, but  
>I tried different compiler versions, described in (2).

gcc-3.4 certainly is nothing you should want to use, imho.
>
>This configuration appears to build the target toolchain with no  
>errors, but when it starts to compile busybox, it errors out on:
>
>/tmp/buildroot/build_x86_64/staging_dir/lib/gcc/x86_64-linux-uclibc/ 
>3.4.6/../../../../x86_64-linux-uclibc/sys-include/asm/param.h:5:32:  
>asm-x86_64/param.h: No such file or directory
>
>I tried linking /tmp/buildroot/build_x86_64/staging_dir/include/asm  
>to /tmp/buildroot/build_x86_64/staging_dir/include/asm-x86_64 just to  
>see how far it would get, and the busybox compile fails here:
>
>console-tools/resize.c: In function `resize_main':
>console-tools/resize.c:61: error: `TIOCSWINSZ' undeclared (first use  
>in this function)
>console-tools/resize.c:61: error: (Each undeclared identifier is  
>reported only once
>console-tools/resize.c:61: error: for each function it appears in.)
>
>
>(2)
>Target Architecture: x86_64
>Target Architecture Variant: opteron
>uClibc C library version (uClibc 0.9.29)
>(toolchain/uClibc/uClibc-0.9.29.config) uClibc configuration file to  
>use?
>GCC Compiler version (gcc 4.1.2)
>
>Almost the same as above, except for compiler versions.  This  
>configuration does not successfully build gcc, and errors out on:
>
>In file included from /tmp/buildroot/toolchain_build_x86_64/gcc-4.1.2/ 
>libmudflap/mf-hooks1.c:58:
>/tmp/buildroot/build_x86_64/staging_dir/x86_64-linux-uclibc/sys- 
>include/unistd.h:243: error: two or more data types in declaration  
>specifiers

If you don't need mudflap, then i suggest you disable it..
Are you preparing a node-image?
>
>I would appreciate any insight you are willing to offer on x86_64  
>builds, as we will be using buildroot extensively in the months ahead.

I'm about to checkin the gcc-4.2.0 support and will then look a little
bit at gcc-4.3 (this is what i will be using, on ia32 boxes, as always).

Generally, i do not use gcc-3.x, nor any binutils older than 2.17, fwiw.
And generally, i think that mudflap is a little bit odd, doesn't work
for me for the most part:
Consider a binary that links against liba.so; this liba.so links against
libb.so, which has an undefined symbol. Now you'd want to print the
libmudflap help-text, and guess what? Since the option (resp. env var)
parsing of mudflap happens after symbol resolution, you will (currently)
never ever be able to trick mudflap into printing *any* help. Last time
i looked, there was no PR about this and i don't have the time to
provide a testcase for this misfeature (since i don't need mudflap).

  reply	other threads:[~2007-06-06 17:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-05 17:16 [Buildroot] problems building x86_64 target kevint
2007-06-06 17:38 ` Bernhard Fischer [this message]
2007-06-06 18:40   ` Bernhard Fischer
2007-06-07  0:31     ` kevint
2007-06-07 10:19       ` Bernhard Fischer
2007-06-11 15:56         ` Bernhard Fischer
2007-06-11 16:28           ` kevint
2007-06-11 22:08             ` Bernhard Fischer
2007-06-11 23:10               ` kevint

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070606173826.GA4543@aon.at \
    --to=rep.dot.nop@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox