[Buildroot] problems building x86_64 target

[Buildroot] problems building x86_64 target

[kevint]

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

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


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.

Thank you for your help,

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070605/0679f3c5/attachment.htm 

[Buildroot] problems building x86_64 target

[Bernhard Fischer]

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

[Buildroot] problems building x86_64 target

[Bernhard Fischer]

On Wed, Jun 06, 2007 at 07:38:26PM +0200, Bernhard Fischer wrote:
>On Tue, Jun 05, 2007 at 10:16:26AM -0700, kevint wrote:

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

ok. svn up, select gcc-4.2.0, binutils-2.17.50.0.9,
kernel-headers-2.6.20
then rm -rf build_* toolchain_* && make

I'll note that the "opteron" support was something i accidentally added
from a WIP for better CPU selection, which is not yet in trunk. Adjust
your custom cflags accordingly for now (as you should always do, fwiw),
via the corresponding menu option.

[Buildroot] problems building x86_64 target

[kevint]

Hello,

Thanks for your tips.  I set --disable-libmudflap in "Additional gcc  
options", and that got past the error I first came across, but I also  
had to modify a couple things to get it to compile the rest of the way:

toolchain_build_x86_64/gcc-4.2.0-final/x86_64-linux-uclibc/libiberty/ 
Makefile (line 368, in install_to_tooldir):

cd $(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR)

to

cd `cd $(DESTDIR)$(tooldir)/lib; pwd -P`/$(MULTIOSDIR)

because my bourne shell was changing directory to the symlinked  
directory, not the physical directory (in which case the relative ../ 
lib64 did not exist).  This is obviously a pretty big hack, so I will  
try to find a more appropriate solution tomorrow.

I also had to copy /tmp/buildroot/toolchain_build_x86_64/linux/ 
include/asm-x86_64 to /tmp/buildroot/build_x86_64/staging_dir/x86_64- 
linux-uclibc/sys-include

to build the rest of the way.  I will try to clean this up a little  
bit in the next couple of days.

Thanks again for your help,

Kevin

On Jun 6, 2007, at 11:40 AM, Bernhard Fischer wrote:

> On Wed, Jun 06, 2007 at 07:38:26PM +0200, Bernhard Fischer wrote:
>> On Tue, Jun 05, 2007 at 10:16:26AM -0700, kevint wrote:
>
>>> 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)
>
> ok. svn up, select gcc-4.2.0, binutils-2.17.50.0.9,
> kernel-headers-2.6.20
> then rm -rf build_* toolchain_* && make
>
> I'll note that the "opteron" support was something i accidentally  
> added
> from a WIP for better CPU selection, which is not yet in trunk. Adjust
> your custom cflags accordingly for now (as you should always do,  
> fwiw),
> via the corresponding menu option.

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070606/881027a5/attachment-0001.htm 

[Buildroot] problems building x86_64 target

[Bernhard Fischer]

On Wed, Jun 06, 2007 at 05:31:25PM -0700, kevint wrote:
>Hello,
>
>Thanks for your tips.  I set --disable-libmudflap in "Additional gcc  
>options", and that got past the error I first came across, but I also  
>had to modify a couple things to get it to compile the rest of the way:

I tried this yesterday and yes, it's broken ATM.
The includes are pretty messed up, could be that the patch in the thread
with subject "sysroot support in toolchain, use correct pathes" in the
archives helps there. This needs proper fixing anyway and this patch
does make it better (didn't try x86_64, though) but since gcc-3.4
doesn't have sysroot support, it breaks in many funny ways, of course.
All vaguely recent gcc -- i.e. the 4.x series onward -- do have proper
sysroot support and work flawlessly.

I'll have a look at it again.

[Buildroot] problems building x86_64 target

[Bernhard Fischer]

On Thu, Jun 07, 2007 at 12:19:48PM +0200, Bernhard Fischer wrote:
>On Wed, Jun 06, 2007 at 05:31:25PM -0700, kevint wrote:
>>Hello,
>>
>>Thanks for your tips.  I set --disable-libmudflap in "Additional gcc  
>>options", and that got past the error I first came across, but I also  
>>had to modify a couple things to get it to compile the rest of the way:
>
>I tried this yesterday and yes, it's broken ATM.
>The includes are pretty messed up, could be that the patch in the thread
>with subject "sysroot support in toolchain, use correct pathes" in the
>archives helps there. This needs proper fixing anyway and this patch
>does make it better (didn't try x86_64, though) but since gcc-3.4
>doesn't have sysroot support, it breaks in many funny ways, of course.
>All vaguely recent gcc -- i.e. the 4.x series onward -- do have proper
>sysroot support and work flawlessly.
>
>I'll have a look at it again.

http://uclibc.org/~aldot/buildroot/buildroot.mine.cow.20070611-1730.diff.bz2

This was tested with sysroot support enabled, gcc-4.2.0. I intend to apply
this once i get a chance to test if building gcc-3.4.6 without sysroot works
as expected.

In the meantime you can use this patch to build a working x86_64 rootfs.

HTH,
Bernhard

[Buildroot] problems building x86_64 target

[kevint]

Hello,

I am comfortable using gcc-4.2.0 now, so that is my new target.  I  
will try out your patch today and let you know how it goes.

I am planning on adding a package for bproc, which includes a kernel  
patch, kernel module, and a few user space daemons and configs.  We  
currently have two supported kernels, 2.6.11 and 2.6.14.  I wrote a  
patch to the 2.6.11 source tree that adds the headers_install  
functionality and patched toolchain/kernel-headers/kernel-headers- 
new.makefile to include a 2.6.11 target, and it seems to work pretty  
well.  I will be doing the same for 2.6.14 later this week.  We are  
targeting 2.6.20 for our next bproc port, but that is a few months off.

Is this something you would be interested in including in the  
buildroot project?

Thanks,

Kevin

On Jun 11, 2007, at 8:56 AM, Bernhard Fischer wrote:

> On Thu, Jun 07, 2007 at 12:19:48PM +0200, Bernhard Fischer wrote:
>> On Wed, Jun 06, 2007 at 05:31:25PM -0700, kevint wrote:
>>> Hello,
>>>
>>> Thanks for your tips.  I set --disable-libmudflap in "Additional gcc
>>> options", and that got past the error I first came across, but I  
>>> also
>>> had to modify a couple things to get it to compile the rest of  
>>> the way:
>>
>> I tried this yesterday and yes, it's broken ATM.
>> The includes are pretty messed up, could be that the patch in the  
>> thread
>> with subject "sysroot support in toolchain, use correct pathes" in  
>> the
>> archives helps there. This needs proper fixing anyway and this patch
>> does make it better (didn't try x86_64, though) but since gcc-3.4
>> doesn't have sysroot support, it breaks in many funny ways, of  
>> course.
>> All vaguely recent gcc -- i.e. the 4.x series onward -- do have  
>> proper
>> sysroot support and work flawlessly.
>>
>> I'll have a look at it again.
>
> http://uclibc.org/~aldot/buildroot/buildroot.mine.cow. 
> 20070611-1730.diff.bz2
>
> This was tested with sysroot support enabled, gcc-4.2.0. I intend  
> to apply
> this once i get a chance to test if building gcc-3.4.6 without  
> sysroot works
> as expected.
>
> In the meantime you can use this patch to build a working x86_64  
> rootfs.
>
> HTH,
> Bernhard

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
phone: 505.667.3488
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070611/532a6208/attachment.htm 

[Buildroot] problems building x86_64 target

[Bernhard Fischer]

On Mon, Jun 11, 2007 at 09:28:56AM -0700, kevint wrote:
>Hello,
>
>I am comfortable using gcc-4.2.0 now, so that is my new target.  I  
>will try out your patch today and let you know how it goes.
>
>I am planning on adding a package for bproc, which includes a kernel  
>patch, kernel module, and a few user space daemons and configs.  We  
>currently have two supported kernels, 2.6.11 and 2.6.14.  I wrote a  
>patch to the 2.6.11 source tree that adds the headers_install  
>functionality and patched toolchain/kernel-headers/kernel-headers- 
>new.makefile to include a 2.6.11 target, and it seems to work pretty  
>well.  I will be doing the same for 2.6.14 later this week.  We are  
>targeting 2.6.20 for our next bproc port, but that is a few months off.
>
>Is this something you would be interested in including in the  
>buildroot project?

2.6.<20 is not interresting for me, personally. I'm currently using
2.6.20.x as my "unified" openswan/bproc/blcr/etc suite and do not
currently plan to move anything else than the very first onward, due to
time-constraints layed upon my scarse spare-time (not in the near future
nor else-wise; If you're interrested in any of these contact me
offline; Likewise if you have specific needs regarding lower-level
communication stacks, this is highly OT. Neither IB nor dolphin nor GM
et al are within the scope of this list, fwiw).

thanks anyway for the offer and nice to see you on-track.

[Buildroot] problems building x86_64 target

[kevint]

I will revisit the topic when we have a stable 2.6.20 bproc package,  
and keep our 2.6.11 and 2.6.14 packages in-house unless someone sends  
me a request for them offline.

We do have specific needs regarding lower-level communication stacks,  
but we have a good handle on them and won't require the mailing list  
to resolve those.  I am mostly interested in a good starting point  
for x86_64 development, which I think we have achieved with the help  
you have provided.

Thanks again,

Kevin

On Jun 11, 2007, at 3:08 PM, Bernhard Fischer wrote:

> On Mon, Jun 11, 2007 at 09:28:56AM -0700, kevint wrote:
>> Hello,
>>
>> I am comfortable using gcc-4.2.0 now, so that is my new target.  I
>> will try out your patch today and let you know how it goes.
>>
>> I am planning on adding a package for bproc, which includes a kernel
>> patch, kernel module, and a few user space daemons and configs.  We
>> currently have two supported kernels, 2.6.11 and 2.6.14.  I wrote a
>> patch to the 2.6.11 source tree that adds the headers_install
>> functionality and patched toolchain/kernel-headers/kernel-headers-
>> new.makefile to include a 2.6.11 target, and it seems to work pretty
>> well.  I will be doing the same for 2.6.14 later this week.  We are
>> targeting 2.6.20 for our next bproc port, but that is a few months  
>> off.
>>
>> Is this something you would be interested in including in the
>> buildroot project?
>
> 2.6.<20 is not interresting for me, personally. I'm currently using
> 2.6.20.x as my "unified" openswan/bproc/blcr/etc suite and do not
> currently plan to move anything else than the very first onward,  
> due to
> time-constraints layed upon my scarse spare-time (not in the near  
> future
> nor else-wise; If you're interrested in any of these contact me
> offline; Likewise if you have specific needs regarding lower-level
> communication stacks, this is highly OT. Neither IB nor dolphin nor GM
> et al are within the scope of this list, fwiw).
>
> thanks anyway for the offer and nice to see you on-track.

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
phone: 505.667.3488
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070611/9ee4ae7a/attachment.htm