[Buildroot] Buildroot + CoudeSourcery 2012.09

[Buildroot] Buildroot + CoudeSourcery 2012.09

[Sören Brinkmann]

Hi,

I recently encountered some weird behavior, and couldn't really find
anything about it.

When I compile a rootfilesystem with CS2012.09 it looks like globbing is
broken, resulting in init scripts are not executed.

Using CS2012.03 and older works fine.

The default shell is ash including bash compatibility stuff.

Did anybody else see something like this?

	Thanks,
	S?ren

[Buildroot] Smallish rootfs for wm8505 netbook

[Peter Faasse]

Hi,

With varying degrees of success, i've been building buildroot based rootfs-s, 
toolchains and kernel images. All part of a hacking project with a few wm8505 
(armv5) based netbooks.

I'm attempting to use buildroot to build a rootfs & kernel that i can use to 
do some native development on the machines. The first set of bugs where no 
doubt caused by my own incompetence and learning curve, but there are one or 
two issues that i think are relevent for a wider audience.

For reference, the target architecture is arm926t; Host is a Slackware-13.37 
x86_64 machine; I'been using both the 2013.02 release of buildroot and the 
git-version as extracted yesterday. I let buildroot itself generate the 
toolchain (no croostool-ng etc..). I did manage to generate a few working 
toolchains, kernel uImages and rootfs.tar images, and i'm in the process of 
generating a fully satisfactory set of target files. But:

1) If i enable c++ support the toolchain, the build of the rootfs will fail 
because of a lack of UCLIBC_HAS_FENV (fenv.h not found). This can easily be 
remedied using make uclibc-menuconfig after configuring buildroot ('Target 
Architecture Features and Options'-->'Enable C99 Floating-point environment'), 
but i think it would make sense if that option is -if possible- automatically 
enabled by activating this uclibc option when c++ support is enabled in 
buildroot itself. 

2) I do include the obsolete 'toolchain on the target'. The resulting gcc on-
target is by default not usable because glibc.so (a linker script it seems) is 
not copied to the on-target directory. This can be remedied by adding *.so to 
the support/scripts/copy.sh, but i'm not quite sure if that has any side-
effects. 

All-in-all i'm having lots of fun with buildroot... :-)

greetings,

Peter Faasse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130502/ff2ac27c/attachment.asc>

[Buildroot] Smallish rootfs for wm8505 netbook

[Thomas Petazzoni]

Dear Peter Faasse,

Please do not reply to an e-mail on the list to start a new thread.
Just send a new mail to buildroot at uclibc.org. Thanks.

On Thu, 02 May 2013 09:00:49 +0200, Peter Faasse wrote:

> With varying degrees of success, i've been building buildroot based
> rootfs-s, toolchains and kernel images. All part of a hacking project
> with a few wm8505 (armv5) based netbooks.
> 
> I'm attempting to use buildroot to build a rootfs & kernel that i can
> use to do some native development on the machines.

We decided to no longer support native development on the target
platform. If you're looking at a full-featured distribution that
provides development tools, installing a Debian armel distribution is
probably a wiser choice.


> 1) If i enable c++ support the toolchain, the build of the rootfs
> will fail because of a lack of UCLIBC_HAS_FENV (fenv.h not found).
> This can easily be remedied using make uclibc-menuconfig after
> configuring buildroot ('Target Architecture Features and
> Options'-->'Enable C99 Floating-point environment'), but i think it
> would make sense if that option is -if possible- automatically
> enabled by activating this uclibc option when c++ support is enabled
> in buildroot itself. 

Strange. Did you do a 'make clean; make' cycle? Can you share a
Buildroot .config that exhibits the problem?

> 2) I do include the obsolete 'toolchain on the target'. The resulting
> gcc on- target is by default not usable because glibc.so (a linker
> script it seems) is not copied to the on-target directory. This can
> be remedied by adding *.so to the support/scripts/copy.sh, but i'm
> not quite sure if that has any side- effects. 

Yes, we know the support for toolchain on the target is broken, and
since no-one every sent patches to fix this, and because we think it's
a bit outside of the scope of the Buildroot project, we decided to
deprecate it.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot + CoudeSourcery 2012.09

[Thomas Petazzoni]

Dear S?ren Brinkmann,

On Wed, 1 May 2013 15:03:16 -0700, S?ren Brinkmann wrote:

> I recently encountered some weird behavior, and couldn't really find
> anything about it.
> 
> When I compile a rootfilesystem with CS2012.09 it looks like globbing
> is broken, resulting in init scripts are not executed.
> 
> Using CS2012.03 and older works fine.

I guess you're talking about ARM ? We don't have support for CS
ARM 2012.09 in Buildroot because it's known to miscompile the Linux
kernel.

So it seems like this toolchain has problems. I think the kernel
problem has been reported to Mentor Graphics, but nothing happened.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Buildroot + CoudeSourcery 2012.09

[Sören Brinkmann]

On Thu, May 02, 2013 at 11:53:58AM +0200, Thomas Petazzoni wrote:
> Dear S?ren Brinkmann,
> 
> On Wed, 1 May 2013 15:03:16 -0700, S?ren Brinkmann wrote:
> 
> > I recently encountered some weird behavior, and couldn't really find
> > anything about it.
> > 
> > When I compile a rootfilesystem with CS2012.09 it looks like globbing
> > is broken, resulting in init scripts are not executed.
> > 
> > Using CS2012.03 and older works fine.
> 
> I guess you're talking about ARM ? We don't have support for CS
> ARM 2012.09 in Buildroot because it's known to miscompile the Linux
> kernel.
Yes it's ARM.
I can compile the kernel just fine with it. Though, I had to cherry-pick
a commit to fix breakage with GCC 4.7.2. Commit 'ARM: 7668/1: fix
memset-related crashes caused by recent GCC (4.7.2) optimizations'
(sha1: 455bd4c430b0c0a361f38e8658a0d6cb469942b5).

> 
> So it seems like this toolchain has problems. I think the kernel
> problem has been reported to Mentor Graphics, but nothing happened.
It's kinda weird. When I use hush it works. So it looks like some
weirdness going on with ash and something in the toolchain.
Google just found some >10 year old issue which seems similar to mine
today. I wonder if that got reintroduced somehow.

	Thanks,
	S?ren

[Buildroot] Buildroot + CoudeSourcery 2012.09

[Thomas Petazzoni]

Dear S?ren Brinkmann,

On Thu, 2 May 2013 09:02:18 -0700, S?ren Brinkmann wrote:

> > I guess you're talking about ARM ? We don't have support for CS
> > ARM 2012.09 in Buildroot because it's known to miscompile the Linux
> > kernel.
> Yes it's ARM.
> I can compile the kernel just fine with it. Though, I had to
> cherry-pick a commit to fix breakage with GCC 4.7.2. Commit 'ARM:
> 7668/1: fix memset-related crashes caused by recent GCC (4.7.2)
> optimizations' (sha1: 455bd4c430b0c0a361f38e8658a0d6cb469942b5).

Ah, interesting. I never it myself, but we had a patch a while ago to
introduce this toolchain, and the submitter said it wasn't working
properly:
http://lists.busybox.net/pipermail/buildroot/2012-November/062026.html.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com